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ABSTRACT 


The  United  Stages  Coast  Guard  is  a  relativ«=-ly  small 
federal  agency  tasked  wirh  a  number  of  duties.  Its  multi- 
mission  nature  a  r.d  lew  budget  is  driving  the  Coast  Guard  to 
realize  tet-er  use  of  its  resources.  A  pivotal  factor  in 
this  gcal  is  the  investment  in  -he  information  systems 
architecture  of  the  future,  today.  Within  the  infcrma-^ion 
architecture,  data  base  technology  plays  an  importan-  rcle. 
Ix  is  to  be  employed  in  major  operat.ional  and  administrative 
systems,  as  well  as  in  the  future  Coast  Guard  District 
Minicomputer  Procurement,  The  purpose  of  -^his  thesis  is  to 
examine  -he  alternatives  available  to  the  U.S.  Coast  Guard 
for    implementing    data   base    technoloay. 
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I-    IN 3 ROD a CTI ON 

A.  BACKGROUND    DISCUSSION 

In  1981,  The  U.S.  Coast  Guard  created  a  new  Office  of 
Command,  Control  and  Communication.  This  Office  has  set 
forth  the  infor nation  architecture  concept  for  the  Coast 
Guard,  which  is  committed  to  investirg  in  the  archi-ecturs 
of  the  future  tcday  so  that  the  Coast  Guard  may  become  an 
"information  corporation"  of  the  1990's.  The  Commandant  of 
the  Coas-  Guard  has  identified  three  critical  success 
factors  (CSF) :  intelligent  terminals,  data  base  management 
systems,  and  telecommunications  networks.  The  intelligent 
terminals  (standard  terminals)  are  already  being  acquired 
and  configured  for  applications.  Da-^-a  base  management  tech- 
nology is  to  be  employed  in  major  operational  and 
adminis-rat ive  systems  under  development.,  as  well  as  in  the 
future  Coast  Guard  District  minicompu-er  procurement.  This 
thesis  will  address  the  Coast  Guard's  second  CSF  -  data  base 
management  systems  -  looking  at  how  the  Coast  Guard  should 
implement  database  technology  in  a  distributed  mode,  given 
the  present  heterogeneous  hardware/software  systems  and 
planned   system  acquisitions. 

B.  RESEARCH    OBJECTIVES 

The  primary  objective  of  this  thesis  will  be  to  provide 
the  Coast  Guard  with  a  strategic  plan  for  implementing  data 
base  technology  given  -he  present  configuration  of  the  Coast 
Guard  and  the  status  of  systems  available  today.  A  secon- 
dary objective  v«ould  be  t.  c  present  what  future  trends  in 
data  base  technology  are  foreseen  and  the  situation  of 
present   data    base  systems  in  general. 
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C.  THESIS    SCOPE,    LIMITATIOHS    AND    ASSUMPTIONS 

The  main  thrust  cf  this  thesis  will  be  an  examination  of 
the  various  Data  Base  Management  System  (DBMS)  architectures 
available  as  well  as  an  examination  of  •'■he  Coast  Guard's 
requirement?  for  data  base  technology.  Future  trends  in 
DBMS  technology  will  be  examined,  realizing  -^.har  the  sys-.eras 
acquired  today  will  be  affected  by  +he  technological 
advances    which    occur      in   the   near    future.  The    researchers 

did  not  confine  -he  scope  of  the  thesis  to  any  one  specific 
organizational  element  of  the  Coast  Guard,  but  ra-^-her 
attempted  tc  corsider  the  reguirement-s  of  the  organization 
as      a    whole.  The    reader      is   assumed      -^.o    have      at    least      a 

cursory    knowledge   of   computer  systems    nomenclature.  (Note: 

The  authors  will  not  attempt  to  use  a  single  spelling  of 
either  "data  base"  or  "database"  but  will  use  both  inter- 
changeably since  both  spellings  are  used  throughout  current 
literature) . 

D.  METHODOLOGY 

The  me-^hcdology  employed  in  this  research  effort  was 
primarily  an  observational  type  approach  coupled  wi-h  an 
extensive  literature  review  of  current  books,  periodicals, 
articles  and  journals,  as  well  as  Coast  Guard  directives, 
plans,  and  policy  guidance.  These  literature  reviews  were 
augmented  by  interviews  with  appropriate  personnel  as  neces- 
sary. These  research  techniques  were  appropriate  because 
they  furnished  Coast  Guard  requirements  while  identifying 
the    available  technologies    and    future    trends. 
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E.       OEGANIZATION    OF    THE   THESIS 

The    following      is   a      breakdown   of      the    various      chapters 
included    in   this   thesis: 

Chapter  II  -  This  chapter  provides  the  reader  with  the 
current  frameviork  or  situation  which  the  researchers 
faced    in    conducting  their    research. 

Chapter  III  -  This  chapter  discusses  some  organizational 
implications  which  may  affect  the  Coast  Guard's  Command, 
Control  and  Communications  program  goals  in  general,  and 
the    data    base    coals    in   particular. 

Chapter  IV  -  This  chapter  discusses  the  future  tech- 
nology develop  nents  in  data  base  managemen-^-  systems  and 
how  these  developments  will  affect  the  currently  avai- 
lable   alternatives. 

Chapter  V  -  This  chapter  provides  a  detailed  description 
of  three  currertly  available  architectures  and  discusses 
the    strengths    and    weaknesses   of   each. 

Chap-^er  VI  -  This  chapter  provides  a  strategy  which  the 
researchers  b^^lieve  the  Coast  Guard  should  employ  in 
implementing   database    technology. 

Chapter  VII  -  This  chapter  provides  a  summary  of  the 
researchers*    conclusions    and   recommendations. 
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II.  RESEARCH  FRAMEWORK 

A.   GENERAL 

The  purpose  of  this  chapter  is  to  give  the  reader  an 
understanding  of  the  framework  which  the  researchers 
addressed  in  forirulating  ^his  thesis.  The  authors  will  give 
a  brief  overview  of  the  missions  assigned  -^  o  the  U.S.  Coast 
Guard  and  then  look  at  how  -^he  Coast:  Guard  is  organized  in 
order  to  accomplish  these  missions.  The  r'^searchers  will 
then  look  a*  the  plans,  policies  and  resources  dedicated  to 
the  Command,  Control  and  Communications  program  of  the  Coast 
Guard  in  supporting  their  mission  objectives.  A  brief  look 
at  the  current  technology  framework  is  included  to  describe 
the  environmen-^  of  the  information  systems  industry  facing 
the   Ccast    Guard    today. 

1  .      Coast   Gujrd    Missions    • 

The  United  S-^ates  Ccast.  Guard  was  created  in  1790  by 
an  Act  cf  Congress  which  was  initiated  by  the  Secretary  of 
the    Treasury,      Alexander    Hamilton.  The    primary    purpose    of 

the  organization  was  initially  zo  collect  tariffs  for  the 
country  to  offset  the  debt  from  the  Revolu-^ionary  War.  This 
organization  was  first  called  the  Revenue  Cutter  Service  and 
had  an  initial  complement  of  10  cutters  with  UO  total  offi- 
cers. In  1915  the  Life  Saving  Service  was  combined  with  the 
Revenue  Cutter  Service  zo  form  the  U.S.  Ccast  Guard.  The 
Lighthouse  Service  was  amalgamated  in  1939.  At  present  the 
Coast  Guard  is  tasked  with  performing  the  following 
missions: 

SEARCH  AND  RESCUE  (S  AR)  :  Locating  and  assisting  persons  and 
property         in      distress        on        the        high      seas         and        U.S. 
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jurisdictional    waters.  Charged  by      the    National      SAR    Plan 

with  total  respcnsibilty  for  SAR  in  the  North  Pacific  and 
most    cf   the   North  Atlantic. 

ENFORCEMENT  OF  lAWS  AND  TREATIES:  Place  territorial  and 
adjacen-  waters  under  surveillance  to  deter  illegal  activi- 
ties, acguire  relevant  data,  and  promote  safety  of  life  and 
property , 

AIDS  TO  HflVIGATICN:  Ooerat  e  and  maintain  a  complex  network 
of  navigational  signals  (e. g.  buoys,  lights,  radio  beacons) 
covering  all  U.S.  jurisdictional  waters,  and  radionavigation 
signal  systems  (lORAN  and  OMEGA)  meeting  the  requirements  of 
the    Department   of  Defense   and   the    civil    community. 

ICE  BREAKING:  Clear  passage  through  frozen  waterways  for 
ship  movements  and  conduct  scien-^.ific  research  in  ice 
covered    waters. 

MARINE  ENVIRONMENTAL  PROTECTION:  Perform  surveillance  of 
maritime  areas  for  evidence  of  discharged  oil,  other  hazar- 
dous substances  and  ocean  dumping  violations.  Prevent 
unauthorized  discharging  and  enforce  applicable  laws  and 
treaties.  Ensure  necessary  containment  and  removal  of 
spills. 

MILITARY      READINESS:  Maintain      an         effective      force        of 

personnel,  facilities  and  equipment  in  a  state  of  readiness 
for    war   or    peacetime   emergency. 

RECREATIONAL  BOATING  SAFETY:  Conduct  safety  patrols,  espe- 
cially in  areas  of  high  beating  density,  instruct  state 
officials  and  the  Coast  Guard  Auxiliary  in  methods  to 
increase  recreational  boating  safety,  and  promote  boating 
safety   through    public   contact. 
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COMMEECIAL  VESSEL  SAFETY:  Develop  safety  standards  and 
enforce  them  through  vessel  and  equipment  inspection,  vessel 
documentation,  investigation  of  accidents  and  violations, 
and    licensing   of   seamen. 

PORT  SAFETY  AND  SECHBITY:  Enforce  laws  and  safety  regula- 
tions. Facilitate  traffic  movement.  Investigate  accidents 
and  violations.  Monitor  leading  operations  and  movement  of 
vessels  carrying   hazardous    cargo   [Ref.    1]. 

The  Coast  Guard  is  -^.he  smallest  of  the  U.S.  Armed 
Services  and  is  unique  in  that  it  performs  these  various 
peacetime  missions  as  opposed  to  the  other  Armed  Forces 
which  really  only  perform  wartime  related  functions.  Having 
a  multitude  of  missions  has  created  some  debate  as  to  which 
department  the  Ccast  Guard  should  belong.  Originally,  the 
Coast  Guard  was  part  of  the  Departmen-^-  of  Treasury,  but  in 
1967  the  Coast  Guard  was  placed  under  the  newly  created 
Department  of  Transportation.  Some  observers  have  stated 
that  the  Coast  Guard  should  be  part  of  the  Treasury 
Department  while  others  feel  it  belongs  wi-h  the  Commerce 
Department.  Another  view  points  out  that  since  the  Coast 
Guard  is  ultimately  an  Armed  Service,  it  should  be  part  of 
the    Depar-ment      cf   Defense.  Table    I      relates    the      various 

missions  which  -^he  Coast  Guard  performs  to  the  Federal 
Department  to  v»hich  that  function  would  be  connected 
[Ref.  2].  Reference  2  points  out  that  there  are  various 
reasons  for  not  putting  the  Coast  Guard  in  either  the 
Department  of  Defense,  Commerce  or  Treasury  and  recommends 
that  the  Ccast  Guard  remain  a  part  of  the  Department  of 
Transportation,  with  which  the  researchers  concur.  But  it 
is  observed  that  there  will  continue  to  be  speculation  of 
relocating  the  Ccast  Guard  as  long  as  it  remains  a  multi- 
missicn  organization.  In  recent  years  this  fact,  along  with 
being      a      relatively    small      organization,         has      contributed 
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TABLE 

I 

_.    -.      , 

Coast   Guard    Missions  by 

Logi 

cal   Department 

MISSION 

1 

LOGICAL    DEPARTMENT            | 

1 

Armed    Force/M  iltary  Readiness 

Defense 

Maritime   Law    Enforcement    / 

Commerce    or 

Navigation 

Transport 

at  ion 

-fisheries, sanctuaries, mamma 

Is 

-Navigation    laws, aids  to   nav 

igati 

on 

-Navigation    faciltation 

Maritime   Law    'Enforcement 

Justice 

-Drug   Interdiction 

-Immigration    Laws 

Maritime   Law    Enforcement 

Treasury 

-Customs   Laws 

Marine    Safety   Functions 

Transporta-^i 

on 

-Search   and    Fescue 

1 
1 

-Aids    to    Navigation 

1 

1 
1 

-Commercial    vessel, boat ing 

- 

and   port   safety 

Marine   Environmental   Protecti 

on 

EPA 

toward  giving  the  Coast  Guard  somewhat  of  a  visibility 
problem.  The  end  result  of  -^^his  visibility  problem  is  that 
it  has  been  difficult  for  the  Coast  Guard  to  get  adequate 
funding  and  resources  in  order  to  properly  carry  out  the 
missions  wi-^h  which  they  are  assigned.  In  1980,  in  combina- 
tion with  the  office  of  Man  agemen-^.  and  Budget  and  the  Office 
of  -^he  Secretary  of  Transportation  the  Coast  Guard  carried 
cut  a  sophistica  ■'•ed  zero-based  personnel  study.  This  study 
considered      the    irissions      currently      assigned      to    the      Coast 


16 


Guard  and  zhe  prcgrani  s-candards  developed  for  current  levels 
of  operations.  The  study  found  that  to  continue  the  current 
level  of  operations  without:  deterioration  of  plant  and 
equipment,  the  Coast  Guard  would  need  between  9,000  and 
15,000  more  personnel  than  they  currently  have.  The  average 
age  of  Coast  Guard  ships  is  27  years  and  there  is  approxi- 
mately a  S2-3  billion  backlog  in  capital  investment  to  its 
aging   shore    facilities  [ Ref .    3]. 

The  bottom  line  with  regard  to  this  discussion  is 
that  the  Coast  Guard  is  a  severely  resource  constrained 
organization  (as  all  organizations  would  probably  admit,  but 
the  researchers  believe  that  the  Coast  Guard  is  especially 
so) .  Let  us  th€n  proceed  to  look  at  how  the  Coast  Guard  is 
organized  to  carry  out  its  missions  and  then  look  into  how 
the    Coast   Guard    handles   its    information    resources. 

E.       CCAST    GUARD    CRGANIZATION 

1 .      General 

The  Coast  Guard  is  an  organization  with  approxi- 
mately 39,000  military  personel  and  6,000  civilian 
employees.  Coast        Guard      Headquarters        is      located        in 

Washington,  D.  C .  and  is  divided  up  into  staff  elements 
responsible  for  -he  various  operational  or  support  programs 
the  Coast  Guard  carries  cut  in  support  of  its  assigned 
missions.  (The  Search  and  Rescue  program  is  an  example  of 
an  operational  program.)  These  staff  elements  are  often 
referred  to  as  program  managers  and  they  set  the  policies 
and  objectives  for  their  respective  programs  according  to 
the  guidance  set  forth  by  the  Commandant  of  the  Coast  Guard, 
a  4-star    flag   rark. 

The  next  organizational  level  in  the  Coast  Guard  is 
broken  down  into  two  Area  Offices  -  the  Atlantic  and 
Pacific,    located   in    New   York   and   San    Francisco   respectively. 
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TABLE  II 

Ccast 

Guard  Districts 

ATLANTIC  AREA 

PACIFIC  AREA            | 

1st: 

Boston,  Ka. 

11th: 

Long  Beach,  Ca. 

2nd: 

St.  Louis,  Mo. 

12th: 

San  Francisco,  Ca. 

3rd: 

New  York  ,  Ny  . 

13th: 

Seattle,  Wa. 

5th: 

Portsmouth,  Va. 

lUth: 

Honolulu,  Ha. 

7th: 

Miami,  Fl. 

17th: 

Juneau,  Al. 

8th: 

New  Orleans,  La. 

9th: 

Cleveland,  Oh. 

1 

Each  Area  is  ther  subdivided  into  Disrrict  regions.  Table 
II  shows  the  brsakdcwn  of  Districts  with  the  loca-ion  of 
each  of  the  District  headquarters.  Each  Distric"^.  is  then 
subdivided  into  Groups,  Stations,  and  Captain  of  the  Port 
zones  depending  on  the  needs  of  each  particular  Dis-.ric"*:. 
The  various  afloat  resources  are  distributed  among  the 
Districts  with  Ccast  Guard  aircraft  being  operated  out  of  26 
different  air  stations.  The  District  Commanders  are  respon- 
sible for  all  operational  ac-ivities  within  their  geographic 
boundaries.  Each  Area  office  provides  administra- ive  and 
operational  suppcrt  and  guidance  when  more  than  one  District 
is  involved  in  a  common  mission.  Since  almost  every  Coast 
Guard  unit  is  considered  mu Itimissioned ,  management  of  oper- 
ational, logistic  and  informational  support  can  be  a 
difficult    task. 

At  this  point,  the  researchers  will  briefly  describe 
how  the  management  cf  information  resources  fits  into  the 
Coast      Guard        organiza-^  ion  al      picture.  Prior        to      1981, 

management    cf      information    resources    was     essentiallly   split 
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between  three  Headquarters'  program  offices  -  OTM: 
telecommunica tiers  division,  SEE:  electronics  engineering 
division,  and  PIS:  information  systems  division.  OTM  was 
responsible  for  the  general  operation  and  technical  perfor- 
mance of  the  Coast  Guard  communications  syst<^m.  OTM  also 
played  a  substantial  role  as  technical  advisor  and  'market- 
ing' agent  for  the  Office  of  Operations  in  translating 
mission  needs  in-^o  system  requirements  for  EEE  to  actually 
acquire.  EEE  was  responsible  for  all  electronics  systems  in 
use  operationally  with  specific  responsibility  for 
computer/information  sysrems  when  used  in  conjunction  with 
these  operational  systems.  FIS  was  responsible  for  alniost 
all  of  the  Coast  Guard's  computer  systems  and  some  special 
data  commun icat i ens  systems.  FIS  was  created  in  the  1950's 
as  primarily  a  group  of  experts  running  and  building  appli- 
cations  on    one   central  computer. 

On  17  March  1981,  t  h-^  Commandant  announced  his  deci- 
sion to  form  a  new  Office  of  Command,  Control  and 
Communication  (G-T)  which  was  a  direc*:  result  of  the 
Decision  Support  Systems  Study  Group  (DSSSG)  report.  The 
most  significant  point  raised  in  this  report  was  that  full 
integration  of  -"he  three  divisions  (OTM,  SEE,  FIS)  was 
necessary  in  order  to  maximize  the  human  and  financial 
resources  available  to  meet  the  unprecented  demands  for 
information   technology. 

The  Office  of  G-T  has  been  subdivided  into  several 
divisions  to  carry  out  the  functions  previously  performed  by 
OTM,  EEE  and  FIS;  in  addition,  it  has  added  a  new  s^aff 
component,  the  Plans  and  Policy  Division  (G-TPP) .  This 
division's  functions  include:  (1)  managing  and  performing 
planning  functiors  for  -:he  alloca^iion  of  Coast  Guard-wide 
resources    to     the  G-T      program,       (2)  Information    Resources 

Management     (IBM)    and    (3)    Data   Resources    Management. 
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A  broad  defini*:iop  for  Information  Resources 
Management  (lEM)  is  the  affective  and  efficient  utilization 
and  control  of  the  resources  (i.e.  hardware,  software  and 
data)  necessary  to  support  the  information  processing 
requirements  of  an  organization.  Information  is  now  seen  as 
a  primary  resource  of  an  organization  in  -^hat  it  allows  the 
members  of  the  organization  to  answer  questions  and  solv9 
problems,  there ty  achieving  organizational  goals.  As  a 
primary  resource,  information  needs  to  be  effectively 
managed  just  as  any  other  resource  (i.e.  manpower  or 
capital)     is   managed    by  an  organization. 

As  pcirt  of  the  1981  formation  of  the  Office  of 
Command,  Control  and  Communication,  seven  5-year  goals  were 
est  ablished : 

(1)  Support  Goal  -  Providing  the  support  and  mainte- 
nance of  installed  hardware/software  systems  occupies 
one-half  of  the  Office  of  G-T.  The  goal  is  to  continue  and 
reduce  the  cost  of  this  support  program  management  with 
continual  sensi-^ivity  to  the  difference  between  actions 
necessary  -^o  maintain  system  performance  and  those  that 
improve  it.  The  la-ter  are  also  the  responsibiltiy  of  the 
support  forces,  but  improvements  must  compete  with  other 
wcr-^hwhils  projects  for  resources.  The  SUPPORT  and 
CPPORTUNITY  goals  are  complementary;  either  one,  if  carried 
to   excess,    can   render   the  other    unachievable. 

(2)  Acquisition  Goal  -  The  Office  of  G-T  is  the 
designated  support  manager  for  acquiring  major  electronic/ 
computational  systems,  and  the  goal  is  to  develop  an 
adaptive  organization  to  carry  out  this  mission  with  project 
management  techniques.  'Acquisition'  is  the  entire  func- 
tion, from  concept  through  deployment  and  acceptance  by  the 
operating  and  support  managers.  'Major'  is  a  case-by-case 
de-cision  reflecting  funds,  quantity,  time,  failure-risk, 
etc.         A    large-dcllar   replacement   acquisition      may    well    be   a 
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support/mair.tena  r.cs      action,      while      a    small      new-technology 
project   could   require    a    'major   acquisition'    project. 

(3)  Opfortunity  Goal  -  The  Office  of  G-T,  in 
pursuing  the  above  two  qoals,  will  have  many  opportunities 
(e.g.,  in  allocation  decisions,  degree  of  budqet  emphasis, 
use  of  small  discretionary  resources,  etc.)  to  tackle  o-her 
goals  of  opportunity.  For  example,  within  the  support/ 
maintenance  environment,  a  familiar  target  of  opportunity  is 
to  seek  improved  performance  in  the  course  of  a 
maintenance-justified  action.  This  goal,  coupled  with  the 
SUPPORT  goal,  is  to  aggressively  pursue  the  use  of  informa- 
tion technology  throughout  the  Coast  Guard  wi-h  •♦■hese 
•opportunity'  resources.  This  service-wide  use  of  informa- 
tion technology  is  to  be  in  accord  with  the  Commandant's 
long  range  goal-seeking  efficiency  through  automation  and 
effectiveness   through   decision    support. 

(4)  Operation  Goal  -  The  Office  of  G-T  is  charged 
with  the  operation  cf  four  facilities  to  directly  support 
Coast  Guard  Headquarters:  Flag  Plot,  COMMCEN,  National 
Response  Center,  and  Terminal  Center,  The  goal  is  to 
increase  the  efficiency  of  this  support,  particularly 
through  use  of  information  technology,  without,  an  increase 
in    resources. 

(5)  Maritime  Communication  Policy  Goal  -  The  Office 
cf  G-T  performs  a  unique  function  in  government  forums 
(domestic  and  international)  in  fields  within  this  umbrella 
subject,  such  as  spectrum  management  and  radio  distress 
policy/technology.  The  goal  is  to  draw  upon  the  increased 
technical  and  senior  management  resources  of  the  new  Office 
to  increase  Coast  Guard  effectiveness  in  this  subject 
without   new   resources. 

(6)  Human  Resources  Goal  -  There  are  two  dimensions 
to  the  goal  for  human  resources  -  the  general  program 
management      of   the      officer      and      enlisted   specialty      groups 
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under  ■•"he  cognizance  of  the  Offica  of  G-T,  and  of  ths 
personnel  assigred  to  the  Office  sraff  at  Coast  Guard 
Headquarters,  In    the   former,      tha   goal    is    efficient    use   of 

these      people    in      meeting   racsx      of    the      above   goals.  This 

requires  considerable  integra-ion  of  previously  separate 
special"^  ies,  development  of  new  career  patterns  and 
retraining.  In  the  case  of  Coast  Guard  Headquarters  staff  - 
particularly  civilian  staff  -  the  goal  is  one  of  opportunity 
for  personal  grcwth  and  development  along  with  the  new 
Office.  Such  d-^velopment  would  be  through  training  and  new 
positions    in    the   new    sub.jects  being   undertaken, 

(7)  Informaticr.  Resources  Management  -  An  accesssory 
function  in  the  support/maintenance  area  for  information 
systems  is  'data  base  administration'.  This  forms  a  core  in 
the  broader  IRt!  subject  which  includes  manual  (paper) 
systems  and  other  topics  such  as  office  automation,  elec- 
tronic mail,  and  teleconferencing.  Future  assignment  of 
these  responsibilities  to  the  Office  of  G-T  is  intended;  the 
goal  is  mature  development  of  the  initial  data  base  concepts 
and  inclusion  within  the  next  several  years  of  -he  manual 
systems    management    into    a   true    IRM   role    for    the   Office. 

The  researchers  consider  the  IRM  goal  to  be  the  most 
significant  and  revolutionary  for  the  Coast  Guard  of  the 
seven    goals      established    by    the      Office    of   G-T.  The    other 

goals  support  already  well  established  programs  in  the  Coast 
Guard,  whereas  IRM  is  essentially  a  new  one,  and  one  which 
the  researchers  believe  is  essential  if  the  'information 
corporation  of  the  1990*  s'  concept  is  to  be  achieved. 
Database  technology  is  one  aspect  of  IRM  in  that  it  supports 
the  IRM  goal.  Iherefore,  recognizing  the  importance  of  IRM 
for  the  Coast  Guard,  the  authors'  will  discuss  IRM  with 
regard  to  the  Coast  Guard's  present  situation,  planned 
growth,  and  how  database  technology  fits  into  the  Coast 
Guard's    IRM    goal. 
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The  follcwing  paragraphs  show  a  breakdown  of  scire  of 
the  factors  which  the  researchers  feel  will  be  affec-.ing  the 
Coast  Guard  in  the  inanaaement  of  information  resources  and 
in  the  attainment  of  the  above  stated  goals.  Assumptions 
and  constraints  ccncerning  these  resources  are  also 
included. 

2.      Cperatio  ral    Resources 

Table  III  shows  the  breakdown  of  the  current  level 
of  major  Coast  Guard  resources.  Drastic  changes  in  the 
level  of  these  resources  is  not  expected  in  the  next  five 
years   especially   in      view  of    the    budget      situation    presently 


TABLE    III 
Coast   Guard  Operational   Hesoarces 

COTTERS:     250 
AIPCRA7T:     173 
BOATS:    2000 
SHORE    FACILITIES:    700 


facing  the  Coast  Guard.  The  Coast  Guard  is  acguiring  11  new 
270  foot  Medium  Endurance  Cutters  which  will  improve  the 
average  age  of  the  fleet  somewhat  when  they  replace  some  of 
the  most  ag^d  vessels.  With  regard  to  operating  resources, 
the  Coast  Guard  will  continue  to  maintain  eguipment  in  the 
most  effective  iranner  and  will  seek  -co  acquire  i:h=  most 
technologically  optimal  systems  available.  Improved  manage- 
ment of  information  resources  is  of  high  importance  in 
allowing    the   Coast      Guard  to    keep   its      operational   resources 
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in  the  highest  level  of   raadiness  possible.    Discussion  of 
infer  ma -^icn  resources  will  be  included  below. 

3 .   Budget 

The  current  level  of  the  budget  for  the  Coast  Guard 
is  approximately  S2  billion  annually.  Of  this  amount,  a 
portion  is  spent  in  supporting  the  Coast  Guard  information 
resource  reguirements  (either  directly  or  indirectly). 
References  U  and  5,  outline  the  budget  and  resource  alloca- 
tion process  to  te  followed  with  regard  to  the  Coast  Guard's 
Command,  Control  and  Communications  Support  program.  These 
policies  are  consistent  with  -rhs  Coast  Guard's  Planning, 
Programming  and  Budgeting  System  (PPBS) .  The  summation  of 
these   policies    is  as    follows: 

(a)  Major  irformation  systems  will  be  capitalized 
through  Acguisition,  Construction  and  Improvement  (ACSI) 
budge-^lng.  Acgusition  will  be  done  by  Coast  Guard 
Headguarters  tc  program  manager  specifications.  AC5T 
billets  will  be  reguired,  and  the  program  manager  will 
need   a    degree    cf   experise    in    sta-iiing    requirements. 

(b)  Small  to  medium-scale  systems  can  be  supported  by 
Resource  Change  Proposals  (RCP) ,  by  a  program's  internal 
funds,  or  by  competition  for  the  Headquarters  Office  of 
G-T's    small,    in-house   resources. 

(c)  Small  to  medium-scale  systems  would  normally  be 
procured  by  the  Office  cf  G-T,  although  the  program 
manager  could  do  this  himself  following  applicable 
standards. 

(d)  Installed  "institutional"  or  Coast  Guard-wide  offi- 
cial systems  will  be  under  the  Office  of  G-T's 
configuration    and    standards    management. 
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(e)       Cperating      expense   f cllow-on    resources      for    mainte-  ■ 
nance      of      inf crmaticnal      management         systems      mus-      be 
identified   for   the    users    for   adequate    provisioning. 

At  any  rate,  although  the  Coast  Guard's  expenditure 
for  information  resources  will  be  increased  in  view  of  the 
previously  discussed  reorganization,  the  overall  Coast  Guard 
tudget  is  not  expected  tc  increase  in  any  significant 
amount,  and  may  actually  decrease  when  the  effect  cf  infla- 
tion is  taken  into  account.  The  researchers  therefore  feel 
that  the  Coast  Guard  MUST  make  prudent  decisions  about  the 
hardware  and  software  it  acquires  today  to  improve  its 
inf  or  ma-ion  resource  management,  in  order  that  it.  does  not 
alienate  many  of  its  members  from  future  use  of  t.his  equip- 
ment through  bad  experiences  with  the  systems  which  are 
purchased   now. 

^  •      Fersonn  al 

As  menticned  earlier,  the  Coast  Guard  is  presently 
made  up  of  abcut  39,000  military  and  6,000  civilian 
employees.  Appendix  A  shows  the  lates-  personnel  resources 
presently  assigned  tc  the  G -T  program.  The  most  important 
note  to  make  concerning  Coast  Guard  personnel  in  the  infor- 
mation resource  arena  is  -hat  there  is  currently  a  critical 
shortage    of   qualified   people,  FY80    estimates    identified   a 

shortfall  cf  approximately  90  professionals  merely  to  main- 
tain existing  systems  and  complete  development  of  already 
initiated  systems.  The  19  81  reorganization  only  served  to 
identify  more  shortfalls  by  opening  up  more  billets  in  the 
information      resource      management      program.  Training      and 

education  are  ob^jious  parts  of  the  solution  to  this  problem, 
tut  meeting  -^.he  Coast  Guard's  needs  will  r'^quire  a  strategic 
approach    to   the    overall    management    and    use    of   personnel. 
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5.      Assnm£;^i  ens    and   Constraints 

The   users  of    the   Command,      Control    and   Comraunica-^  ion 

(G-T)    prcaram   ar-E  the   entire    Coast    Guard   plus   parts   of    other 

goverment    agencies   and  the    maritime    community.         This    thesis 

assumes   no    basic   changes    in      the   traditional   organization    or 

mission    tasking. 

There  will  te  little  or  no  expansion  in  the  total 
resources  available  to  -he  G-T  program,  although  it  will 
continue    to   compete    vigorously    in   the    budget    process. 

The  core  of  -he  G-T  program  strategy  will  be  one  of 
centrally  providing  concept  design,  standards,  acquisi-^ion 
and  control  of  major  systems  or  application  of  major 
resources   throughout    the   entire    Coast   Guard. 

There  is  a  family  of  externally  imposed  requirements 
which  impac-^-  on  -^he  manner  of  execution  of  the  G-T  program. 
These  are,  generally,  the  original  Brooks  Act  which  empowers 
GSA  with  sole  ?DP  equipment  procurement  authority;  the 
myriad  of  computer-related  Federal  procurement  and  Federal 
Property  Management  Pegulations  which  implement  the  Brooks 
act;  ether  Federal  Regulations  and  various  interagency 
agreements.  These    factors      will   be      discussed    in      greater 

detail   as   acpropiiate  [Ref.    U  ], 

6  .      ADP    Bgui  pmer.t 

a.      Existing    Tools    and   Facilities 

The  following  paragraphs  contain  a  brief  list  of 
present  facilities  which  in  some  manner  support  Coast  Guard 
inf  or  ma-^icn      processing.  In      the         next      section,  the 

researchers  will  discuss  the  future  information  architecture 
developments  beir.g  planned  for  the  Coast  Guard.  The  authors 
discuss  the  present  resources  in  order  to  show  thai  these 
resources  consist  of  outdated  equipment  put  together  in 
disjoint    systems,      which   appear    to      have   evolved    in    response 
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tc  narrowly  scoped  require  ment  s  withouT  considera-tior.  for 
consolidating  th€  facilities  which  perforin  similar  functions 
into      more        effective,         general      purpose        systems.  The 

researchers  want  to  ccnvey  the  image  that  CoasT:  Guard  infor- 
mation systems  are  currently  behind  the  times,  and  can  be 
better  managed,  but  that  positive  steps  are  being  taken  in 
tha-^  Coast  Guard  is  realizing  its  problems  and  is  taking 
action   tc   correct  the  situation. 

Communications      Stations      and    Padio      Stations 
These    facilities      provide   personnel   resources      and   equipment 
for    data    transfer  shcre--o- shore   and    ship-to-shore. 

Electronics  Engineering  Center  and  Electronics 
Engineering  Laboratory,  Sta-^ion  Alexandria  -  these  provide 
electronics  engineering  personnel  expertise  for  field 
maintenance  management,  field  testing  and  special  systems 
development. 

Command  Centers  (Communicaticns  Centers  and 
Operations  Centers)  -  these  provide  the  nuclei  for  contin- 
uing command  and  ccntrol  of  all  Coast  Guard  operations; 
provide  a  continuity  of  management  of  all  activities  during 
ncn-wcrking  hours;  provide  for  the  management  of  all  elec- 
tronic information  flows  into  and  out  of  District  offices; 
and  they  will  become  increasingly  dependent  upon  information 
technology. 

Leased  lines  and  GTE  TELENET  Packet  Switching 
Network  -  Leased  lines  are  procured  from  the  teiephon'^ 
company  and  provide  the  equivalent  of  a  pair  of  wires  from 
pcint  tc  point  -  these  are  now  used  extensively  in  landline 
communications  and  in  the  District  data  network;  GTE  TELENET 
is  a  shared,  computerized  communications  system  which  the 
Coast  Guard  has  selected  as  a  critical  augmenting  resource 
for    servicewide    communications   needs. 
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AOTOCIN  -  currently  AUTODIN  is  the  backbori'^  of 
EoD  messaqe  and  store-and-f  cr ward  dat??.  communications,  and 
provides  the  bulk  of  intar-dis -crict  message  communications 
for  the  Coast  Guard;  DoD  does  not  charge  for  this  service; 
DoD  is  currently  designing  a  packet  switching  replacement, 
similar  to  GTE  TELENET  network;  FAA  is  designing  a  similar 
one,  called  NADIN  II,  which  the  Office  of  the  Secretary  of 
Transporattion  (CST)  is  considering  for  a  Department  -  wide 
network. 

Model  28  Teletype  mechanical  communications 
terminals  -  these  terminals  are  physically  and  technologi- 
cally very  old  and  are  becoming  extremely  difficult  to 
maintain  in  operation;  -hey  have  very  low  capacity  (75  bits 
per  second,  abou":  100  words  per  minute)  and  possess  no  capa- 
bility   for    intelligent   message    handling. 

VHF/IM      and    H?      Radio      Communications    Systems 
installed      radio    networks      provide   the      bulk    of      operational 
command    and   control    for    mob ile -units,       and    coordination   with 
civilian    marine    traffic. 

District  Northern  Telecom  DATA  100  Remote  Job 
Entry  Terminals  -  these  are  high-speed,  in-elligent  termi- 
nals which  can  be  programmed  in  a  short  time  to  communicate 
over  leased  or  dial-up  lines  with  a  variety  of  computer 
equipment  in  several  protocols;  they  can  also  be  programmed 
to  execute  simple  processing  locally  in  a  language  called 
RPG;  these  currently  support  the  bulk  of  district  data 
processing  needs  with  the  Transportation  Computer  Center 
(TCC)    and    local    processing. 

Word  Processing  Systems  -  in  use  at  various 
locations  in  -^he  Coast  Guard  serving  primarily  word 
processing  and  some  list.  processing  functions;  some  have 
higher  processinc  capability;  many  can  be  used  in  a  communi- 
cations environcent,  and  can  be  utilized  as  terminals; 
wherever  appropriate  and  economical,  these  systems  will 
remain   in   place. 
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Mini  and  microcomputers  -  various  models  exist 
throughout  'he  Coast  Guard  supporting  important  functions 
for  local  needs;  as  long  as  these  needs  are  being  satisfied 
in   an   economic   manner,    these   systems   will   remain    ir.    place. 

Operations  Computer  Center  (OCC)  and  Computer 
Centers  at  Aircraft  Repair  5  Supply  Center  (ARSC)  ,  Academy, 
Coast  Guard  Yard,  and  Supply  Center  at  Brooklyn,  NY  -  These 
major  processina  centers  will  provide  special  processing 
needs   to    programs  or    facilities. 

DOT  and  Other  Governmental  Computer  Service 
Centers  (i.e.  TCC,  Transportation  System  Center,  FAA 
Aeronau-^ical  Center,  National  Institutes  of  Health,  Walter 
Reed  Army  Hospital,  Navy  Fleet  Numerical  Oceanography 
Canter)  -  these  systems  provide  general-purpose  computing 
resources  to  th?  Coast  Guard,  on  a  reimturseable  basis, 
shared   by    o-her    agencies. 

Commercial  Timesharing  -  Competitive  single-user 
contracts,  GS A  Multiple- award  schedule  contracts,  and 
DOT-wide  multi-u=er  contracts  under  negotiation;  the  advan- 
tages of  this  type  of  service  are  firs-,  higher  levels  of 
analytical  assistance  and  second,  usually  more  reliable* 
on-line,  interactive  service;  this  better  service  carries  a 
higher   cost. 

For  the  interested  reader.  Reference  4  contains 
an  inventory  of  the  software  systems  cuurently  in  use 
throughout    the   Ccast    Guard. 

t.      Projected     Coast     Guard        Information      Resources 
Architecture 

The  purpose  of  this  section  is  to  give  the 
reader  an  understanding  of  how  the  Coast  Guard's  existing 
resources  and  facilties  will  be  expanded,  reconfigured  and 
utilized  in  the  next  5-10  years.  References  4  and  6  provide 
a  more   detailed    description    of   this  topic. 
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The  words  infcrmation  and  da-ta  have  various 
meanings  and  sometimes  the  words  are  used  interchangeably. 
The  Ccast  Guard  has  decided  to  refer  to  data  as  static  enti- 
ties with  assigned  definitions.  Information  is  ^he  enhanced 
meaning  of  value  associated  with  these  data  when  they  are 
somehow  processed  or  utilized  by  human  or  machine  inteli- 
gence.  As    an      introduction   to      the      Coast   Guard's      future 

inforna-^icn  resource  (IR)  architecture,  it  is  useful  to 
think  about  infcrmation  in  three  global  ways  in  which  the 
organization  uses  it  -  namely  hierarchical,  transactional 
and    local    information. 

Figure  2,1  shows  hierarchical  information 
flowing  from  th€  smallest  unit,  to  the  -^cp  of  the  Coast 
Guard,  and  ultimately  beyond  to  both  Congressional  and 
Executive  recipients.  Hierarchical  information  supports  the 
management  contrcl  and  strategic  control  functions  of  the 
organization. 

Figure  2.2  shews  transactional  inf  crm_ation, 
based  upon  data  groupings  that  flow  intact  from  point-to- 
point  in  the  organization  and  usually  cause  or  support  rapid 
activity. 

Local  information  is  anything  and  everything 
that  any  indivicual  or  organizational  element  chooses  to 
utilize  when  it  is  not  institutionally  required  to  do  so. 
Strategic  design  of  the  information  architecture  recognizes 
the  use  and  need  of  local  information  for  maximum  user 
benefit.  The    architecture      must      provide   some      reasonable 

facility  for  each  level  of  the  organization  to  meet  its 
Iccal    information    needs. 

Figure  2.3  shows  the  merger  of  traditional 
record  communications  and  future  data  communications.  The 
various  networks  are  simply  treated  as  resources  to  move 
data,  and  it  becomes  a  network  management  task  to  insure 
that      operational      transactions    are      handled      with      adequate 
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Figure   2, 1        Hierarchical    Information. 

priority.  3y  implementing  most  data  communications  as  an 
enhanced  version  of  record  communications,  upward-compatible 
and  gracuaTsd  giowth  is  achieved,  as  well  as  the  loosest 
possible  dependence  between  physically  separate  information 
resource    elements. 

An  important  feature  of  the  information 
resources  architecture  is  the  new  Coast  Guard  Standard 
Terminal,  This  piece  of  equipment  has  been  chosen  to  be  the 
primary  * standar cized*  computer  hardware  device  in  the  Coast 
Guard    for      the    1980's.  It    can    be      viewed    as      a    relatively 

inexpensive   device    with   three  essential    features: 
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Figure  2.2  Transactional  Information- 
la)  Ccmmun icat icn  -  the  terminals  can  ccmmunicate 
ever  all  of  the  channels  planned  for  Coast  Guard  use, 
with  software  and  hardware  supplied  by  the  vender. 
They  can  also  be  clustered  among  themselves  for 
sharing  of  processors  and  data,  with  the  wire  inter- 
connection   being  the   communication    channel. 

(b)  Human  Interface  -  with  its  CP.T  screen,  software 
and  keyboard  it  can  easily  be  used  by  all  levels  of 
Coast  Guard  personnel.  The  special  function  key?  and 
electronic  generation  of  f ill-in-the-blank  forms  make 
it  capable  of  being  viewed  as  only  marginally 
different  from  paper  and  pencil,  functioning  as  the 
source   of   data    for    all    three  types    of    information. 
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Figure  2.3        0- S .  Coast   Guard  Planned    Information    Architecture. 
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(c)  Prccess/Storage  -  The  medium  sized  microproc^sscr 
(Intel  3086)  presenr  in  each  trrminal  gives  them  -^.he 
ability  to  mee*  nearly  all  local  information  needs 
for  the  198C's.  In  addition,  standing  alone  i*  can 
perform  many  of  the  formal  transactional  and  hier- 
archical  processing   functions  [Ref.    U], 

Thre€  categories  of  communications  networks  will 
be  used  by  the  Coast  Guard  in  the  1980-1990  time  frame. 
These  are  an  outgrowth  of  the  Coast  Guard's  command  hier- 
archy and  the  record  message  store  and  forward  communication 
mode.  These   three      categcries   of      networks   are      national, 

regional    and    local    networks    as   shown    schematically    in    Figure 
2.U. 

NATIONAL  NETWOfK  -  The  National  Network  is  a  generic 
term  which  encompasses  those  means  of  interconnecting 
major  Coast  Guard  national  switching  nodes.  (The  major 
switching  nodes  are  presently  Districts,  communications 
and  radio  sra-ions.  Any  possible  combination  of  uncon- 
nected ne'TWorks  may  be  chosen  in  -he  future  but  today's 
Coast  Guard  'National        Network'  consists  of 

SARIANT/SARPAC  (Ccast  Guard  search  and  rescu<^  systems), 
AUTCDIN,  Secure  Command  and  Control  Network,  (all  three 
interfaced  by  iranual  tcrn-"^ape  operation),  TELENET,  and 
the    Isased    Infcrmation   Network. 

REGIONAL  NETWCRK  -  the  r'=gional  network  will  provide 
ccnnecticn  and  infcrmation  exchange  between  the  regional 
nodes  and  local  nodes  (end  user  terminals  or  local  area 
networks) .  T tis  is  analagcus  to  the  District  or  Group 
Teletype   net.  (Both   National   and   Regional   Networks    may 

ultimately  end  up  using  the  same  network  technolgy  as 
ARPANET.) 

LOCAL  NETWORK  -  The  local  network  will  provide  connec- 
tion  and    inforiraticn  distribution    (exchange)    between   the 
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Figure    2.4        Coast    Guard    NETWORKS. 

local  network,  or  local  area  network  (LAN)  as  rhey  are 
popularly  called  and  connect  users  intra-buildir.q, 
intra-f acilit y   or      intra- industrial    park.  Examples   of 

present  LAN's  are  a  shared  logic  word  processing  system 
connecting  all  offices  in  a  Dist.rict  Office,  a  loop  of 
Model  28  Teletypes  controlled  by  an  HP9825  or  on-base 
administrative   teletype      systems.         In    the      future   -hese 


35 


LAN's  will  b€  much  more  capable  of  handling  large 
volumes  of  information  and  a  heterogeneous  mix  of  users 
(such    as    Wang    ^■et)    [Ref.    6]. 

The  Coast  Guard's  last  main  feature  of  the 
information  resource  architecture  is  that  of  data  resource 
management.  This  concept,  deals  with  the  fact  that  data  is 
an  important  resource  of  an  organization  and  that  th*^ 
management  (the  collection,  storing  and  processing)  of  the 
data  is  a  crucial  determinant  for  the  smccsss  of  any  planned 
information   resource   architecture  of   that    organization. 

The  focus  of  this  thesis  is  concentrated  in 
looking  at  how  the  Coast  Guard  addresses  the  problem  of 
information  resource  management  via  DBMS  technology.  More 
will  te  discussed  concerning  planned  growth  for  Coast  Guard 
information   systems    in   Chapter    VI. 

C.       TECHSOLOGY    FEAMEWCHK 

The  researchers  will  now  discuss  how  the  current 
'state-of-the-art'  has  evolved  in  computer  or  informa"^ion 
systems  environnent  specifically  with  regard  to  data 
resource    management. 

When  computers  were  first  introduced  in  the  1950 's  hard- 
ware cost  was  the  mcst  significant  factor.  The  computers 
were  relatively  slow  (especially  when  compared  with  -oday) 
and  designed  primarily  for  the  solution  cf  sophisticated 
mathematical  numter  crunching  problems.  As  the  speed  of 
computers  improved,  the  ability  of  computers  ro  process  a 
la^ge  amcun-  of  repetitive  data  was  recognized  and  computers 
began  to  be  utilized  increasingly  for  'management-related' 
processing  (i.e.  payrolls,  personnel,  inventories,  etc.). 
But  still  throughout  the  1960's,  the  computer  was  viewed  as 
a  large,  expensive  machine  kept  in  a  central  location  and 
operated        by      specially         trained,        dedicated        personnel. 
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EfficieTiCy  cf  the  machine  was  s-tressed  iue  to  its  high  cost, 
and  if  it  just  so  happened  that  the  reports  a  manager  was 
getting  were  not  responsive  to  his  needs,  then  getxing  a  new 
report  created  was  not  an  easy  task.  This  was  because  one 
had  to  get  the  analysts  and  programmers  together  from  the 
data  processing  department,  tell  them  what  was  necessary, 
and    have   them   write      a  new    program   to    do    it.  If    it    didn't 

turn  out  the  correct  way,  a  person  might  no-  go  back  to 
change  it  because  of  all  the  trouble  to  do  so.  Data  in  this 
type  of  situation  was  probably  centrally  located,  but  as 
discussed,    getting   tc   the   data    was  often   not    very    easy. 

With  the  revolution  of  integra'^'ed  circuits  and  silicon 
chips,  the  speed  of  computers  increased  greatly  while  -he 
price  of  computers  decreased  even  greater.  Mini  and  then 
microcomputers  were  introduced  with  recognition  that  not  all 
situations  reguire  a  large  mainframe  and  often  it  is  advan- 
tageous to  have  several  smaller  computers  instead  of  one 
great  big  one.  'Power  to  the  people'  has  been  used  to 
describe  this  philosophy  of  providing  a  small,  low-priced 
computer  directly  tc  a  user  in  order  to  be  more  responsive 
to  his  particular  needs.  As  data  sharing  needs  grow,  these 
independent  smaller  ccmputers  can  be  interconnected  to  form 
networks  or  distributed  systems.  'EFFECTIVENESS'  (utilizing 
the  computer  -^o  achieve  optimal  assistance  to  us=rs  in 
meeting  their  needs)  rather  than  'EFFICIENCY'  (achieving 
optimal  utilization  cf  the  computer)  becomes  the  important 
factor    with  regard   to    this    type   of   computer   architecture. 

But,  as  is  the  case  in  a  changing  world,  when  you  solve 
old      problems,        new    ones      often      appear.  As   the      use      of 

computers  grew,  and  more  people  used  them,  more  programmers 
appeared  and  often  different  sections  or  departments  in  the 
same  organization  developed  their  own  programs.  This  was  in 
part  because  the  organization  wanted  to  make  the  computer 
more    responsive    and    give  the      end   users    better   control,      but 
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problems  with  data  redundancy  and  consistency  appearsd. 
Each  department  tegan  maintaining  their  own  set  of  aa-.a,  and 
often  this  data  was  repeated  in  several  departments. 

This  led  to  the  development  of  data  base  management 
systems  in  order  to  allow  sharing  of  data,  to  control  data 
integrity,  to  allow  greater  data  independence,  and  to 
improve  data  r ecoverabili ty  [ Ref -  7].  These  data  base 
management  systeirs  are  sophisticated  software  products  which 
provide  for  effective  management  of  data  resources,  and  when 
combined  wi-^h  a  special  query  language  can  be  utilized  by  a 
non -specialist  user  to  quickly  access  the  data  base  in  a 
responsive  manner.  Mcst  of  these  DBMSs  are  designed  for  a 
single  computer.  The  Coast  Guard  has  decided  on  a  policy  of 
distribution  of  computer  resources  in  which  the  information 
resources  (hardware,  software  and  data)  are  placed  in  the 
hands  cf  -he  commander  who  exercises  responsibity  and 
control  over  the  forces  they  support.  Therefore  the  Coast 
Guard  faces  a  problem  of  managing  data  resources  given  a 
distribution  of  those  resources. 
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III.    OBGANIZATIONAL    IMPLICATIONS 

A.  GENEEAL 

In  this  chapter,  the  researchers  would  like  to  take  a 
look  at  -^he  overall  direction  the  Coast  Guard  is  headed  with 
respect  to  information  systems  and  database  technology,  and 
then  relate  this  direction  with  what  is  happening  in  the 
information  systems  industry  at  this  time.  The  authors  will 
discuss  some  organizational  impacts  which  may  be  expected  as 
a  result  of  the  actions  "caken  by  the  Command,  Control,  and 
Communication    program      of   the      Coast    Guard.  Finally,      the 

researchers  will  provide  some  recommendations  for  planning 
for  and  dealing  v»ith  these  impacts  in  order  to  minimize  any 
negative   effects. 

B.  DIEECTICH   CO  i!ST    GOAED   IS    HEADED 

The  direction  the  Coast  Guard  appears  to  be  taking  in 
the  information  resource  management  (lEM)  area  seems  -^o  be 
one  of  greatly  increasing  the  impor-i-ance  cf  and  improving 
IBM  •'•hrcughout  1 1-e  organization.  This  is  evidenced  by  the 
reorganization  and  consolidation  of  the  organizational 
elements  involved  in  this  program,  and  the  commitment  of 
spending  more  dollars  on  upgrading  IBM  capabilites.  The 
major  goals  of  the  Command,  Control  and  Communications 
program  wers  outlined  in  Chapter  II  of  this  thesis,  and  the 
Coast  Guard  appears  to  be  pursuing  these  goals  in  a  system- 
atic manner  with  controlled  growth,  coordinated  acquisition 
policies,  and  expansion  of  education  and  training  opportuni- 
ties for  personnel  in  this  area.  The  researchers  feel  very 
strongly  that  th  <=  overall  direction  of  improving  the  effec- 
tiveness     of   IBM      by      the  Ccast      Guard      is    highly      valuable. 
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somewhat  cvsrdue,  and  will  put  the  organization  in  a  bettar 
position  to  overall  manage  its  total  resources.  The  use  of 
data  tas€  technology  is  just  one  avenue  for  increasing  the 
effectiveness      of  an      organization's    lEM.  What    are      ether 

related  technologies,  and  hew  does  -^he  Ccasr  Guard  stand 
with    respect   to    these  concepts? 

Reference   9      discusses    some   of      the    new      -technologies    in 
the      lEM    field      which  are      available   at      this  time.  These 

include: 

1  •      13^1  Ml5  clin^ 

Most  organizations  have  realized  the  importance  of 
having  mcst  printed  text  in  machine  readable  form  in  order 
to  speed  up  the  production,  update  and  correction  of  printed 
documents.  Often  referred  to  as  word  processing  systems, 
these  type  systeiis  can  be  obtained  as  a  microprocessor  dedi- 
cated to  this  task  or  as  a  feature  of  a  general  purpose 
computer  system.  The  Coast  Guard  has  implemented  word 
processing  systems  in  varying  degrees  throughout  the  organi- 
zation. These  range  from  the  simple,  stand-alone  dedicated 
systems  to  sophisticated,  interconnected,  multiuser  systems. 
The  Office  of  G -T  has  decided  that  wh6r<=  cost-beneficial, 
these  systems  can  be  continued.  The  standard  terminal  is  an 
example  of  a  general  purpose  system  which  can  be  used  for 
word    processing. 

One  common  extension  of  word  processors  is  the 
ability  to  electronically  send  documents  between  processors 
in  differen-^.  locations  in  lieu  of  having  to  manually  trans- 
port the  hardccpy.  Therefore,  it  is  necessary  for 
communication  standards  to  be  established  in  order  that  the 
machines  can  coirmunicate  with  one  another  over  the  estab- 
lished protocols.  Standards  for  interfacing  dedicated  word 
processors  with  larger  general  purpose  computer  systems 
should   also   be   required.      The  Coast    Guard   has   recognized   the 


UO 


importance  of  such  standards  and  has  promulgated  the  proto- 
cols   to    be      utilized   by   the    affected      equipment    in    Reference 

a. 

2 .      Messaqinc 

This  concept  is  related  to  the  feature  discussed  in 
word  prccessors  on  electronically  sending  documents,  but 
should  be  con!^icered  as  a  more  general  feature  than  iust 
sending  documents.  Messaging  conveys  the  idea  of  using  the 
information  system  as  a  means  to  send  communication  between 
individuals  without  having  person--^  o- person  or  telephone 
con-^act.  This  concept  is  often  referred  to  as  electronic 
mail.  An   example      of   messaging      would    be      a   system      which 

allows  text  messages  to  be  sent  from  terminal  to  terminal 
enabling  a  person  to  use  the  terminal  directly  for  reviewing 
incoming  messages  thereby  cutting  down  on  actual  paperwork 
and  speedina  up  the  communication  in  the  process  (i.e.  no 
busy  signals) .  Another  example  might  be  a  variation  which 
would  allow  recorded  voice  messages  to  be  dispersed  by  the 
computer,  similar  to  what  a  telephone  answering  machine  does 
for  incoming  calls,  allowing  the  message  *--0  be  sent  to  more 
than  one  destination.  This  would  relieve  -^he  originator  of 
the  time  consuming  task  of  calling  a  lot  of  oxher  people  and 
getting   many   busy  signals. 

The  idea  of  messaging  can  be  extended  to  having  a 
computer  conference  where  the  messages  are  senx  back  and 
forth  in  an  online  mcde,  thus  alleviating  the  need  -c  have 
actual  personnel  travel  to  one  geographic  site  in  order  to 
conduct  the  conference.  Since  some  people  find  conferencing 
by  computer  too  impersonal  and  hard  to  follow,  the  next 
extension  is  to  *ransmit  video  signals,  or  teleconferencing. 
The  Coast  Guard  presently  has  some  systems  capable  of  elec- 
tronic mail  type  messaging,  although  long  distance  sys-^ems 
are    net      in    place  at    this      time.        Continued   growth      in   this 
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area  can  be  expected  given  the  rising  costs  of  transpcr":  ing 
personnel  and  the  decreasing  costs  of  computer  and  telecon- 
ferencing  systems. 

3.      distributed    Systems    and    Networks 

The  concept  of  distributing  computing  resources 
(hardware,  software,  and  data)  is  currently  a  ma-jor  topic 
throughout  the  computer  industry.  A  tremendous  amount  of 
research  is  being  conducted  in  looking  at  how  computer 
networks  and  distributed  sys-^-ems  can  improve  the  effective- 
ness and  user  satisfaction  of  today's  informaricn  systems. 
The  researchers  will  use  -he  following  definition  of  a 
distrtu+red  systen:  first,  the  system  should  possess  two  or 
more  gecgraphically  separated  processors,  second,  the 
processors  should  he  linked,  and  third,  the  processors 
should      serve      a    single      organizational      entity.  Computer 

networks  can  be  generally  defined  as  a  connection  of  two  or 
more  computers  vhich  are  able  to  communicate  between  on'= 
another.  Examples  of  computer  networks  include  the  Advanced 
Research  Projects  Agency  (APPA)  Network  and  IBM's  System 
Network  Architecture  (SNA)  .  Note  that  a  distributed  system 
is  a  computer  network,  but  not  every  computer  network  is  a 
disrribu-^ed   system  [  Ref -    8]. 

As  previously  menticned,  the  Coast  Guard  has  decided 
on  a  principle  cf  distribution  of  computing  resources  to 
some  extent.  The  Coast  Guard  will  build  upon  message 
store-and-forwar d  communication  as  its  principal  mode  of 
interconnection.  True  computer  processor  interconnection  in 
the  style  of  IBP's  SNA  will  be  discouraged  for  the  near 
term.-  The  reascn  for  this  policy  is  based  on  the  principle 
of  prudent  evolution.  There  is  no  forseen  great  payback  to 
the  Coast  Guard  for  implementing  computer  networking  of  the 
SNA-type  systems  at  this  time,  especially  considering  the 
high   technical-skill   and   supports  costs   of   SNA  [Ref.    4].      An 
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important  pcint  the  Coast  Guard  should  consider  when  imple- 
menting its  present  systems  is  to  design  for  future  change 
and  recognize  that  computer  networking  and  distributed 
systems  are  the  direction  information  systems  are  headed. 
Therefore,  the  Coast  Guard  should  strive  for  compatibility 
and  standardization  as  much  as  possible  in  order  to  have 
systems  capable  cf  becoming  networks  when  such  a  configura- 
tion   is    considered   economically    feasible    and   desirable. 

^  •      P^cisio  n    Su££crt    S^st  ems  (DSS) 

Decision  Support  System  is  also  currently  a  highly 
discussed  topic  in  the  computer  field  today.  Some  consider 
it  to  be  the  latest  'buzz-word*  in  the  industry,  picking  up 
where  Management  Information  Systems  (HIS)  left  off.  Many 
critics  feel  that  DSSs  are  no  different  than  MISs  and  zhdiZ 
the  new  term  has  simply  evolved  so  that  salesmen  can  sell 
more  systems.  Eut  many  others,  including  the  researchers, 
feel  that  DSS  is  an  independent  concept,  and  that  it  refers 
to  building  an  information  system  to  be  readily  u-^ilized 
primarily  tc  support  the  decisions  which  an  individual  in 
the  organization  has  to  make.  Some  components  of  a  DSS 
would  probably  include:  an  interactive  query  or  dialogue 
capability,  a  database  managemenr  system,  a  modeling  capa- 
bility, and  a  graphics  capability.  Some  observers  consider 
the  modeling  capability  as  the  feature  which  distinguishes  a 
DSS  from  an  MIS,  while  others  believe  its  distinction  to  be 
that  it  is  primarily  designed  for  the  particular  indivdual 
or    job    position    for    whose  decisions   it    is   meant    to    support. 

At  any  rate,  the  researchers  feel  that  the  Coast 
Guard  will  most  likely  be  inves-ing  in  decision  support 
systems  in  the  future,  as  these  systems  seem  to  fall  nicely 
into  the  gcals  ar.d  objectives  which  the  Coast  Guard  has  set 
for  its  Command,  Control  and  Communications  program.  The 
researchers    are      aware   of      at  least      one    DSS      in    use      in   the 
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Coast  Guard  which  is  installed  in  the  First  Coast  Guard 
Bistric-^  in  suppcrt  of  the  operations  center  controller  for 
search   and    rescue   decision    making. 

5.      Cata   Ba§i  MiiI-^3§M2;^   Systems 

This  thesis  discusses  in  some  detail  the  status  of, 
goals  and  objectives  of  database  management  systems.  The 
researchers  believe  that  the  Coast  Guard  is  realizing  the 
importance  of  DBKS,  and  specific  recommendations  regarding  a 
strategy  for  implementing  database  technology  are  included 
in   Chapter    VI. 

The  Coast  Guard  is  in  varying  stages  of  installing 
database  technclcgy.  The  Marine  Safety  Information  System 
(MSIS)  has  been  in  development  for  over  10  years  and  will 
contain  a  sophisticated  DBMS.  With  regard  to  the  District 
miniccmputer  procurement,  the  Wilson-Hill  study,  [Ref.  10], 
has  been  viewed  as  a  'jumping  off  point  for  developing  the 
logical  data  bas?  design  t c  be  urilized  by  the  CoasT  Guard 
Districts.  A  pilot  project  for  designing  the  logical  data- 
base is  underway  in  -he  First  Coast  Guard  District  and  it 
has  been  reported  that  they  are  attempting  to  integrate  the 
Districts'  database  reguirements  for  this  design  with  those 
of   other      Coast    Guard     organizational    elements.  This   will 

hopefully  ensure  a  standard  Coast  Guard  data  dictionary, 
which  the  researchers  believe  is  essential  for  the  success 
of  this  project.  A  target  date  of  April  1983  has  been 
projected    for   the   initial  draft   of  this    design. 

The  authors  will  next  discuss  some  of  the  factors 
which  may  influence  the  Coast  Guard  in  pursuit  of  the  goals 
of   the   Command,     Control    and    Communication    program. 
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C.       ISFLDENCING    PACTCES 

The  researchers  believe  that  the  following  facrors 
organizational  change,  resistance  to  change,  -^-echnological 
change,  governirent  procurement  regulations,  and  support 
requirements  -  will  most  likely  have  some  impact  on  the 
Coast  Guard  as  a  result  of  installing  information  in  data- 
base management  systems.  The  authors  will  proceed  to 
discuss  these  implications  in  more  detail  and  describe  what 
effects    they    may   cause   in  a n    organization. 

The  first  factor  which  may  have  an  impac"^.  on  the  Coast 
Guard  in  implemerting  database  technology  and  other  informa- 
tion resource  management  goals,  in  fact,  already  has 
occurred  -  organizational  change.  As  was  mentioned,  one  of 
the  initial  events  which  triggered  the  Coast  Guard's 
emphasis  on  inforraaticn  and  data  resource  management  was  the 
reorganization  of  the  Headquarter ' s  divisions  of  OTM,  EEE 
and  FIS  into  the  Office  of  G-T.  But  there  are  other  less 
evident  ways  in  which  the  introduction  of  dara  base  tech- 
nology may  change  the  organization.  These  changes  will  be 
in  the  way  in  which  particular  individuals  perform  their  job 
and  also  in  the  informal  organizational  structure  of  the 
Coast  Guard.  Hopefully,  the  new  systems  will  improve  or 
make  easier  the  tasks  which  Coast  Guard  personnel  carry  out. 
This  is  one  of  the  reasons  -^he  new  systems  were  introduced 
in  the  first  place.  The  informal  structure  of  the  organiza- 
tion refers  to  the  fact  that  in  order  to  get  things 
accomplished,  the  formal  organizational  structure  is  not 
always  strictly  followed,  and  informal  working  relationships 
often  crop  up.  By  introducing  new  technology,  changes  in 
this  informal  structure  can  be  expected  as  new  users  of  the 
systems  in-^-erac^  with  other  users  who  either  work  in  a 
similar  manner  with  the  system,  or  are  more  knowledgeable. 
The  effects  of  the  changes  can  be  beneficial  or  harmful 
depending   upon   the   productivity    of   these   relationships. 
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The  nex"*-.  factor  which  might  influence  the  Coast  Guard  in 
this  area  is  resistance  to  change.  By  this,  the  researchers 
are  referring  tc  the  idea  that  no  matter  hew  much  one 
prepares  for  changes  in  the  organization,  there  should  be 
some  expectation  that  not  every  one  is  going  to  accept  the 
new  system  (i.e.  there  will  be  resistance).  These  may 
appear  such  as  a  senior  enlisted  radioman  who  becomes 
disgruntled  at  +he  thought  of  having  a  computer  take  over 
the  job  he  used  to  do;  or  providing  a  computerized  sysrem, 
such  as  computerized  inventory  system,  to  an  employee  who 
developed  the  old  system  and  is  highly  familiar  with  it. 
These  types  of  personnel  can  be  expected  to  'buck'  the  new 
system  and  therefore  their  reactions  should  be  considered  in 
order  to  make  the  system  work,  because  without  their 
interest,  involvement  and  support,  the  new  system  will  most 
likely   fail. 

Other  factors  which  should  be  considered  are  rhe  impact 
of  new  technology,  and  th&  effect  of  Government  procurement 
policies      and      regulations.  Technology      in      the      computer 

industry  seems  to  continue  to  improve  upon  itself  at  an 
amazing   rate.  Yet    forecasters    predict    that      technology    in 

the  computer  industry  will  contiue  to  get  better,  and  there- 
fore the  Coast  Guard  must  be  aware  of  this  improving 
environment      and    be      ready    to      take   advantage      of    it.  The 

authors  believe  that  the  Coast  Guard  should  strive  to 
acquire  homogeneous  systems  whenever  possible.  This  will  be 
discussed  in  Chapter  VI.  It  is  noted  that  the  Brooks  Act 
seems  directly  contrary  tc  this  goal  in  the  interest  of 
stimulating  competition  in  the  industry.  Other  regulations 
such  as  GSA  having  sola  procurement  authority  over  ADP 
equipment  must  be  taken  into  account  when  planning  for  and 
acquiring    new    systems.  One   might   think   that      the   bureauc- 

ratic procurement  regulations  of  the  Federal  government 
would   be   somethirg   that   the    Coast   Guard    should   be    well   aware 
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of;  tut,  as  (3iscuss*=d,  for  the  most  part  -^he  Coast  Guard  is 
really  only  now  purchasing  its  own  computer  systems  havina 
leased  timesharirg  servica  primarily  in  the  past.  Therefor* 
the  Coast  Guard  should  take  heed  of  the  lessons  learned  by 
ether  Federal  agencies,  particularly  the  Department  of 
Defense,  with  regard  to  the  long  lead  times  involved  in 
procuring  ADP  equipment  and  plan  early  to  spend  a  consider- 
able amcunt  of  effort  in  order  to  keep  up-to-date  systems. 
Another  major  factor  the  Coast  Guard  must  contend  with  is 
the  supper-  requirements  necessary  for  these  systems  to 
properly  function.  These  requirements  include;  personnel, 
facilties,  training,  maintenance  (of  both  hardware  and  soft- 
ware) ,  security,  and  perhaps  most  importantly,  dollars.  The 
first  couple  of  requirements  are  somewhat  obvious  in  that 
everyone  should  realize  that  computer  systems  need  people  to 
run  them,  buildings  to  put  them  in,  cables  to  run  between 
them,  etc.  The  aspect  of  training  can  often  be  overlooked, 
especially  when  one  considers  the  importance  of  follow-on 
training.  Table  IV  [Ref.  11]  is  an  example  of  the  training 
needs  of  the  dctabase  administrator  and  staff  in  a  DBMS 
environmen-*: .  This  list  indicates  the  extensive  training 
required  to  ensure  proper  operation  of  the  system,  and  also 
the  need  to  hav«=  competent  professionals  working  with  the 
system  in  order  to  educate  the  non-sophisticated  user  (of 
which  there  is  likely  to  be  a  majority  of  in  the  Coast 
Guard,    at    least     initially). 

Maintenance  cf  hardware  is  not  considered  to  be  an  over- 
whelming constraint,  as  hardware  systems  have  become  more 
and  mora  reliable,  hut  backup  procedures  must  be  planned  for 
in  the  case  of  hardware  failures.  The  biggest  factor  in  the 
maintenance      area  is      that    of      software    maintenance.  Hera 

again  i-^.  must  be  pointed  out  that  the  Coast  Guard  is  rela- 
tively new  in  the  ccmputar  business  and  therefore  there  is 
not    a      lot    of  experience      in    dealing    with      computer   systems. 
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TABLE    IV 

_  ,   ^ 

Duties   of   DBA    and   Staff    in   a   DBMS    Environment 

DESIGN    AND    AD fINSISTR ATI  ON 

Define   schemas   and   subschemas 

Select   and    maintain   data    model 

Select   and    maintain   DBMS    software 

ADMINIST!?ATION 

Liaison    with    users 

Training   and    assistance    of  users 

OPERATION 

Formulate    and   enforce   procedures    for    security    5    pr 

ivacy 

Initiate   and    enforce   procedures    for    recovery    5    int 

egrity 

Define,    create,    update,    and    retire    data 

MCNITCBING 

Measure   and    mcnitcr  performance   of    DBMS    resources 

Log   and    monitor    usage    of    DBMS    resources 

Schedule   usage 

Monitor   security    threats 

As  these  systems  become  available,  more  and  more  programs 
(software)  will  inevitably  be  written.  Therefore  software 
engineering  principals  need  to  be  stressed  early  on  so  that 
the  software  written  today  can  be  maintained  tomorrow. 
Experience  from  EoD  has  shown  that  software  maintenance  is  a 
tremendous  concern  and  is  probably  the  largest  expenditure 
on  DoD  computer  systems  -oday.  DBMS  should  aid  in  this  area 
by  introducing  the  concept  of  data  independence  into 
programs  written  for  Coast  Guard  computers  equipped  with 
such    systems. 
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Security  refers  tc  the  concept  that  the  physical  compo- 
nents must  be  protected  from  threats  such  as  theft, 
vandalism,  and  natural  disasters,  as  well  as  protecting  the 
privacy  and  confidentially  of  the  data  stored  within  the 
system.  Security  shculd  be  a  primary  consideration  of  any 
computer  installation  and  DBMS  should  assist  by  providing 
access  ccntrol,  integrity  checks,  security  and  auditing 
features. 

The  last  iteir  mentioned  is  probably  a  result  of  taking 
care  of  some  of  the  ether  factors  which  were  discussed,  and 
this  implies  that  it  takes  money  to  properly  install  and 
operate  an  information  system.  The  Coast  Guard  must  realize 
that  it  is  going  to  take  a  considerable  afflcunr  of  additional 
funding  in  order  tc  properly  operate,  maintain  and  keep 
current  the  computer  information  systems  it  is  installing 
today. 

D.       MINIMIZING    NEGATIVE    IMPLICATIONS 

The  folllowing  are  some  general  recommendations  and 
comments  which  the  researchers  feel  would  assist  the  Coast 
Guard  in  minimizing  negative  implications  associated  with 
introducing    information   systems. 

The  first  ccmment  is  that  the  Coast  Guard  must  design 
for    change.  Tfce   Coast      Guard    must      take    into      account    the 

effect  which  charging  technology  will  have  on  its  informa- 
tion systems,  as  well  as  predict  that  user  needs  will  most 
likely  expand  and  therefore  change  as  they  become  more 
familiar  with  the  systems  as  time  goes  on.  Therefore,  the 
Coast  Guard  needs  tc  design  systems  which  are  flexible  and 
changeable.  This  concept  has  been  repeatedly  stressed  in 
software  engineering,  of  which  modularization  and  change- 
ability  are    key    principles. 
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Along  with  this  'design  for  change'  concept  goas  th^ 
principle  cf  requiring  good  documentation  for  all  the 
systems  which  are  acquired.  This  concept  is  especially 
crucial  in  a  military  organization  where  personnel  rotation 
policies  guarantee  that  almost  all  the  people  who  are 
present  when  a  n€w  system  is  installed  will  probably  be  gone 
after  2-4  years.  This  factor  indicates  that  the  documenta- 
tion cf  the  system  had  better  be  sufficient  and  up-tc-dat= 
in  order  for  new  personnel  to  understand,  operate  and  main- 
tain the  system.  The  Coast  Guard  can  learn  another  lesson 
from  CoD,  which  has  reported  many  instances  of  poor  documen- 
taticn  cf  systems  which  a  f *-.er  a  short  while,  led  to  a 
situation  where  no  one  really  knew  how  the  system  worked. 
Therefore,  if  the  Ccast  Guard  expects  to  be  able  to  under- 
stand  and   maintain    its  systems,    good    documentation    is    vi*al. 

Another  factor  which  will  help  minimize  negative  impli- 
cations is  for  the  Ccast  Guard  to  maintain  top  level  support 
of    its    information    management   goals.  If   top   level    support 

exists,  then  the  chances  of  success  are  much  greater; 
however,  if  this  support  is  not  evident,  then  failure  is 
almost  assured.  This  statement  seems  most  obvious,  but  it 
appears  to  the  researchers  that  it  is  often  overlooked.  One 
problem  involved  here  may  be  that  the  technology  associated 
with  the  information  systems  which  are  being  introduced 
today  is  probably  much  different  than  what  most  top  level 
managers  are  experienced  with.  This  could  lead  to  intimida- 
tion of  the  senior  level  supervisors  to  the  point  that  they 
will  avoid  using  computers  in  order  that  they  do  not  appear 
ignorant   in      front    cf     their   subordinates.  If    the      senior 

level  managers  are  net  using  the  systems,  th=^n  their  subor- 
dinates may  not  feel  inclined  to  use  them  and  eventually  the 
funds  to  support  the  systems  might  be  cut  or  even  shut  off 
completely.  Therefore  top  level  support  can  be  seen  to  be 
an  important  ingredient  to  the  success  of  a  system,  but  how 
can    this    senior    level   support  be   achieved? 
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This  qu-^stion  l  =  ads  into  the  next  pcin*  which 
importance  of  hunan  needs.  The  researchers  f^el  that  one  of 
the  best  ways  in  which  to  achieve  -t-op  level  support  for  a 
system  is  to  have  them  involved  with  and  using  the  system. 
It  has  already  teen  mentioned  that  senior  level  personnel 
may  be  intimidated  by  a  computer,  and  it  should  be  noted 
that  they  probably  dcn't  have  a  lot  of  extra  time  to  spend 
learning  how  to  use  the  system.  Therefore  one  way  to  get 
them  tc  use  it  is  tc  make  the  system  easy  to  learn  and  easy 
to   use.  Reference    12      points    out      seme   excellent      general 

design   principles  which    should      characterize   a   user   oriented 
interactive  system.       These    principles    include: 

1.  Self  explanatory  -  the  system  should  display  suffi- 
cient inforiraticn  to  the  user  without  having  to  go  to 
another   source    for  explanation. 

2.  Self  helpina  -  the  system  should  provide  a  checking 
cf  user  inputs  and  reminders  or  further  instructions 
en    user   request. 

3.  Simple  interfacing  -  the  system  only  requires  actions 
which    are   short,    simple   ana   obvious. 

U.  Interaction  by  anticipation  -  the  system  anticipates 
all  Dossible  desires  of  the  user  in  advance  and 
provides  orcmpts  or  menus  so  that  the  user  can  select 
the  desired  option  in  lieu  of  explicitly  specifying 
it. 


Optional  verbosity  -  the  system  provides  another 
level(s)  of  detail  so  that  the  user  can  obtain  more 
detailed      irformation    en      a   particular      item,       if      so 


level(s)       of  detail   so    that      the    user    can   obtain    more 
detailed      irformaf 
desired   [Bef.    12]. 

By   utilizing  these   design   principles,    most   systems    would 

be   easier      to   learn      by   most      users.         But      even    with      these 

features,        seme   personnel      are    going      to   require      a   lot      of 

'hand-holding'    a rd   training    to   be  a   satisfied  user.      Another 

important    item      to    remember      when    designing      a   system      is    to 

always      include    representatives      of      the      end   users      in      the 

design   committee  .        This   will  often    turn    up   obvious    problems 

and    peculiar     needs    by     the    end      user    representatives      which 

would   not      have    turned      up    from      the    other      design    committee 

members    and      thereby    saving      a   lot      of    expense      altering    the 


51 


system  just  aft<=r  installation.  This  membership  on  the 
design  ccmmittee  also  helps  promote  a  feeling  of  early 
involvement  with  the  new  system  which  can  help  cut  down  on 
the    resistance    tc  change. 

The  bottom  line  is  that  system  designers  must  take  into 
account  the  needs,  capabilities,  and  shortcomings  of  the 
human  user  in  order  that  the  system  be  responsive  -o  user 
requirements,    easy   tc   learn    and   easy   to    use. 

E.       SDHHABT 

In  summary,  this  chapter  pointed  out  several  organiza- 
tional implications  such  as  organizational  change, 
resistance  -^o  change,  and  support  requirements  which  the 
Coast  Guard  should  consider  when  planning  for  information 
systems.  The  researchers  believe  that  the  Coast  Guard  is 
headed  in  the  richt  direction  with  its  information  and  data 
resource  management  policies,  and  that  good  implementation 
practices   are      being   followed      by   the      Coast   Guard.  Coast 

Guard  system  designers  must  take  into  account  human  needs 
and  shortcomings  so  that  the  information  systems  it  employs 
are  usable  as  well  as  efficiency  and  productivity 
improvements. 

The  followinc  chapters  of  this  thesis  will  proceed  to 
discuss  data/database  management  techniques  and  trends,  and 
then  investigate  the  alternatives  open  to  the  Coast  Guard. 
The  researchers  will  match  the  Coast  Guard's  particular 
needs  against  the  various  DBMS  alternatives  available  and 
make  recommendations  as  to  the  direction  the  Coast  Guard 
should   take    in    this    area. 
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IV.  PUT ORE  TECHNOLOGY  DEVELOPMENTS 

A.   GENEEAL 

Before  proceeding  further,  it  is  advantageous  to  explore 
the  new  technologies  that  are  evolving  today.  In  the  field 
of  computing,  it  is  not  surprising  to  see  advances  in  tech- 
nology that  mak€  the  eguipment,  policies,  and  practices 
obsolete      in    just      five   or      ten    years.  For  example,        the 

computer  industry's  architecture  has  progressed  through  four 
generations  of  machines  in  thirty  years  -  from  electrical 
accounting  machires  (EAM)  to  vacuum  tubes  to  transistors  to 
integrated  circuits.  Similar  growth  has  been  experienced  in 
the  logical  viev  and  management  of  data;  flat  files  with 
recor d-at-a-time  serial  access,  to  indexed  sequential  files 
capable  of  random  access  to  data,  to  sophisicated  data 
bases.  The  physical  level  is  no  exception  either  as  IK  bit 
chips  w<=^re  used  in  the  late  1 96  0 » s  while  today  6UK  bit  chips 
are  standard  in  irost  machines  with  256K  bit  chips  available 
en   some. 

Any  strategy  must  take  into  considera-^ion  the  impact  of 
technology.  Therefore,  this  chapter  will  discuss  those 
items  that  +oday  promise  to  have  the  most  impact  on  da-*:abase 
management  systens  (DBMS)  in  the  next  five  to  ten  year  time 
frame.  The  most  promising  areas  are  in  mass  storage  hard- 
ware and  software,  memory,  database  machines,  and 
distributed    database    manage nent    systems. 

Although  the  conceptual  views  of  DBMSs  have  gone  through 
technological  changes,  these  views  have  more  or  less  settled 
down  into  three  basic  models  -  hierarchical,  network  or 
plex,  and  relational.  These  models  will  be  discussed  in  a 
later   chapter. 
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B.       ASSOCIATIVE    COMPUTER    ARCHITECTURE 

Traditionally,  access  to  data  in  main  memory  has  been 
accomplished      by   hardware      address.  This      is   a      necessary 

consequence  of  the  von  Neumann  computer  architecture. 
However,  the  most  desirable  way  to  access  non-numeric  data 
is  by  value.  Programmers  and  users  of  computer  systems, 
especially  those  employing  DBMSs,  think  of  problems  and 
solutions  in  terns  of  value,  not  hardware  address.  As  the 
computer  industry  matured,  a  number  of  methods  were  used  to 
convert  an  external  value  in-^o  an  internal  computer  or  peri- 
pheral device  address.  Most  of  these  methods  are  still  in 
use  today,  e.g.  sequential,  indexed,  hashed,  and  set  access 
methods. 

As  data  bases  became  larger  and  larger,  and  access  was 
required  to  mor€  and  more  data,  computer  performance  was 
kept  to  an  acceptable  level  by  brute-force  improvements  in 
hardware  speed;  i.e.  integrated  circuits,  more  bits  per 
chip,  etc.  The  one  basic  element  that  never  changed  was  the 
von  Neumann  architecture.  Today,  computer  scientists  are 
beginning  -^o  rethink  the  foundation  on  which  computer 
science  has  been  built  and  are  investigating  contents 
addressable   memory,    or  associative  storage. 

Assccia-^ive  processing  systems  generally  have  the 
following  five  basic  components  -  data  register,  mask 
register,  data  array,  word  select  register,  and  search 
results  register.  As  shown  in  Figure  4.1  [Ref.  13]  the  Data 
Register  contains  the  value  to  be  searched,  while  the  Mask 
Register  indicates  what  par-^  of  rhe  Data  Register  is  to  be 
used  for  the  search.  The  Data  Array  contains  the  data  to  be 
searched,  the  Word  Select  Register  indicates  which  words  in 
the  Data  Array  are  to  be  checked,  and  the  Search  Results 
Register  contains  a  M*  bit  for  those  values  in  which  there 
was    a      match.         A      Multiple    Match      Resolver    indicates      which 
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Figure  4.1  Associative  System- 
value  was  found  first.  From  a  casual  inspection  of  Figure 
4.1  it  is  apparent  that  the  size  of  the  Data  Array  contains 
an  upper  bound  which  limits  the  size  of  a  data  base  •'■hat  can 
be  searched  using  parallel  associa-^ive  s+ore  in  a  single 
storage  cycle.  Vihat  is  typically  being  done  is  a  sequential 
associative  search  on  large  portions  of  sequentially  stored 
data.  This  gives  the  logical  effect  of  parallel  associative 
store    if    not   the   speed. 

This  type  of  architecture  is  being  experimented  with 
today  in  a  number  of  ways.  One  idea  is  to  build  an  intelli- 
gent controller  based  upon  associative  processing,  and  place 
it   between      a   general   purpose      computer     (which      contains   the 
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DBMS  softwara)  and  zhe  mass  secondary  s-.orage  device  cf  -ch"? 
data  tas€.  The  Intelligent  controller  would  accept  a  parsed 
request  from  th<=  computer,  and  process  the  transaction 
against  the  data  base.  Another  approach  is  to  incorporate 
this  architecture  into  the  computer  itself.  More  will  be 
said   cf   this    lat^r. 

C.       MEHOBY 

The  driving  force  behind  the  rapid  advances  in  the 
computer  industry  has  been  microelectronics.  The  growth 
depicted  in  Figure  4,2  [Ref.  1U]  was  predicted  in  1964  by 
Gordon  Moore,  the  director  of  research  at  Fairchild 
Semicondutor.  To  date  the  curve  has  been  pretty  accurate. 
Whether  or  not  this  trend  continues  is  speculative,  but 
current  technology  has  not,  reached  its  limit  with  regards  to 
physical  laws.  Further,  as  the  number  of  components  per 
circuit  increases,  the  cost  per  bit  drops;  one  cent  per  bit 
using  IK  chips  in  the  late  1960 's  to  one  tenth  of  a  cent  per 
bit  using  6UK  chips  in  1979.  These  developments,  especially 
with  respect  to  irain  memory  storage,  have  great  consequence 
for  DBMSs,  because  main  memory  serves  as  a  buffer  area  to 
operate  secondary  mass  storage.  The  larger  the  main  memory, 
the  fewer  I/O  ir.terrupts  required  to  accomplish  a  process. 
Hence,  performance  requirements  for  large  data  bases  can  be 
kept  to  wi-^hin  acceptable  limits  as  sizable  portions  of  a 
data  base  can  b€  kept  in  main  memory  without  having  the 
processor    page   data    in  and    cut   of   secondary   mass    storage. 

Secondary  storage  devices  too  have  been  developing  a-  a 
similar  rate.  Charged  coupled  devices  (CCD)  are  available 
in  6UK  chips  with  256K  chips  soon  becoming  available. 
Bubble  memory  is  available,  but  it  is  not  as  popular  as  CCD, 
perhaps  because  it  has  slower  access  times  for  large  amounts 
of   data.      Research    is   still    on- going   in    this   area. 
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Figure   4.2        Growth   in   Hicoelectronics. 

D.       DATABASE    MACHINES 

Today  when  people  talk  of  database  machines,  there  is  no 
common  agreement  on  the  architecture.  In  fac"^.  anything  from 
a  master-slave      conf igur ari on    (a      general   purpose      processor 


57 


HOST   PROCESSOR 


Database 

Management 

System 


X 


Host  Language 
Interface 


-i 


S. 


Query 
Language 


Operating  Systems 
Access     Methods 

^ 


Application 
Request 


OFFLOAD  DBMS  FUNCTION 


BACKEND  PROCESSOR 


Controller 

rr- 


fC^   <!b=i  <i> 


Data 


Data 


Data 


CURRENT  ARCHITECTURE 


Host 
Processor 


Application   Request 


■n 


Request   /  Response 


Database  Processor 


Database  Management  System 


Access  Method 


-A 


Controller 


Data 


Tic:^- 


Data 


Data 


Figure  4,3   Current  DBMS  Architectures. 
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which    performs   all    of  the   data    base   activi-^ies)    to    a    special 
purpose    hack-end   with   intelligent   con*--roller,    is    considered 
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Figure   4.4        Future  DBMS   Architectures. 

to  have  a  database  machine  architecture.  Figures  U. 3  and 
4.U  are  some  of  the  ways  DEMSs  are  integrated  in  computer 
architecture:,  toth  present  and  future.  The  underlying 
concept  of  a  database  computer,  regardless  of  the  given 
configuration,  is  to  off-load  a  portion  or  all  of  the  DBMS 
system      functions      from     the     general      purpose     CPU.  This 
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approach  probably  had  its  impetus  in  the  front-end  proces- 
sors which  isolated  complex  and  sophis-t- ica-^  ed  communications 
and  messaqe  processing  capabilities,  and  placed  those  func- 
tions  in    a    specially    designed   separate    processor. 

There  are  a  r.umber  of  factors  today  which  make  the  off- 
loading of  DBMS  functions  very  desirable.  First,  user 
application  requirements  are  requiring  larger  and  larger 
data  bases.  Th€  very  volume  of  data  is  beginning  to  create 
performance  problems  with  the  length  of  time  necessary  to 
locate  the  '^.ata.  In  some  cases  the  overhead  for  indexes  and 
tables  consumes  irore  than  the  data  itself.  Typical  issues 
any  DBMS  must  ad  cress  are  (1)  the  organization  of  an  inte- 
grated data  base,  (2)  the  storage  locations  for  data  in  the 
system,  (3)  the  location  of  data  in  the  system,  (4)  the 
control  of  concurrent  addresses  and  (5)  -he  mechanisms  and 
structures  -^.o  provide  securi*-y  and  integrity.  in  addition, 
more  and  more  functions  are  being  required  in  the  DBMS.  As 
the  variety  of  these  functions  of  a  DBMS  increase,  so  does 
its  overhead  with  an  accompanying  reduction  in  response  time 
and    throughput. 

The  first  attempts  to  ease  the  overhead  and  performance 
problems  of  DBMS's  consisted  of  using  a  general  purpose 
tack-end  computer  to  replace  database  management  software, 
on  I/C  routines,  and  on-line  secondary  storage.  Although 
this  has  provided  a  partial  solution  to  the  bottleneck  prob- 
lems, the  following  factors  have  mitigated  against  its 
popularity.  The      irarginal      value      of      a      general      purpose 

back-end  computer's  performance  are  in  most  cas«s  much  less 
than  the  marginal  costs  of  the  machine,  it  is  not  uncommon 
to  have  multiverdor  coordination  difficulties,  and  reli- 
ability of  the  total  system  went  down  as  a  result  of  using 
both  the  hcst  and  back-end  (if  one  goes  down  the  whole 
system   crashes. ) 
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By  specialization,  i.e.  associaxivo  addressing  ir  ar. 
intelligent  I/O  controller  (discussed  earlier),  in  conjunc- 
tion with  special  purpose  hardware,  significant  improvements 
result  which  ease  the  performance  bottlenecks  of  present-day 
software-laden   OEMS.  The    reason,         in   a      special    designed 

processor  the  need  for  floating  point  hardware,  long-word- 
size  registers,  and  fast  multiply  and  divide  logic  are  not 
required.  Instead,  byte  manipulation  and  high  speed  I/O 
capability  to  a  wide  variety  of  storage  devices  can  be 
accommodated,  providing  the  potential  for  significant 
improvements.  There  is  much  research  needed  in  this  area, 
tut  it  shows  soire  premise,  and  is  attracting  some  of  the 
best  minds  in  industry  and  the  academic  environment.  For 
example,  Sperry  Dnivac  is  working  with  Dr.  David  K.  Hsiao  in 
exploring  the  coirmerical  potential  for  his  DaxaBase  Computer 
[Ref.    13:    p.    1]. 

E.       DISTHIBDTED     EBftS 

Another  approach  being  explored  to  solve  the  bottleneck 
performance  problem  of  DBMS  software,  dis-^ributed  data-base 
technology,  attacks  the  problem  from  an  altogether  different 
perspective.  The  major  benefits  claimed  are  increased  data 
availability  to  the  end  user  and  reduced  exposure  to  total 
system  failure  due  to  hardware  or  software  failure 
[Bef.  15].  Because  data  processing  and  storage  capabilities 
are  distributed  to  the  location  of  data  origin  or  end  use, 
faster  and  easier  access  tc  the  data  can  be  provided  than 
under  a  traditional  centralized  DBMS.  However  the  facili- 
ties fcr  data  organization  access  and  control  must  be 
extended  to  include  the  following  CODASYL  recommendations  in 
a  Network   DataBase    Management  System    (NDBMS)  : 

1.  Intercept  a  user  request  and  determine  which  nodes  to 
send  it  to  for  processing.  The  majority  of  user 
requests  should  use  local  data  and  r.c-  require  the 
NDEMS.  These  may  go  tc  the  local  DBMS  directly  or  be 
passed   to    it  by   the   NDBMS. 
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2.  Access   the      network    iirectory    (which   may      possibly   be 
r€ircte)     for    the    above    purpose. 

3.  If   the   target    data    are    on   multiple    nodes,      coordinate 
the    use   of    these   nodes. 

4.  Manage  the    communication   between      its    node   and   DBHS*s 
in    ether    nodes. 

5. 


w^  -  ..^ogeneo  usness  m  this  context  implies  difrerances 
between  hardware  (and  software)  elements  in  each  node 
in    the   system. 

Thus  in  distributed  data  base  technology,  faster  access  to 
data    in-^rcduces    nore    complexity    to   the    overall  system. 

Maintaining  data  base  accuracy  with  concurrent  updates 
to  the  same  data  item,  maintaining  the  internal  consistency 
of  the  data  base,  and  maintaining  the  consistency  among  the 
various  copies  of  -he  data  base,  collectively  comprise  what 
is      known   as     ccrcurrency      control.  This   is      the      primary 

research  area  in  distributed  database  technology.  One  may 
think  that  having  heterogeneous  hardware  and  software  compo- 
nents migh-*:  create  the  most  difficulty  in  a  distributed 
system,  but  this  is  not  so,  Heterogeneousness  does  however, 
add  to  "-he  complexity  of  the  system.  It  is  believed  that 
before  a  distributed  DBMS  can  achieve  wide  acceptability, 
the  update  synchronization  or  concurrency  problem  must  be 
solved. 

A  number  of  methods  or  techniques  are  being  explored  to 
solve   the      update  synchronization      problem   [Bef.    16].  The 

first  is  global  locking  where  all  the  copies  of  the  data  are 
locked,  the  update  is  applied  to  every  copy,  and  all  the 
locks    are   then    released.  This   approach    effectively   solves 

the  concurrency  problem,  but  at  an  unacceptable  price  in 
high    system   overhead.  The    second   method    is      dominant   copy 

synchronization  where  one  copy  in  the  distributed  system  is 
dominant      and      updated      first.  This      dominant      copy      then 

controls  the  rest  of  the  updates  at  the  different  nodes. 
This      method    is      acceptable    for      systems      having    low      updat'^ 
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frequency,  tut  becomes  the  source  of  a  bottleneck  if  upda-es 
are  high,  or  if  updates  are  time  critical.  The  third  method 
utilizes  -^imest  a  ips  instead  of  locks.  The  id=a  presented  is 
that  timestamps  ere  appended  to  every  data  item.  The  data 
ar  the  node  can  te  updated  if  the  rimestamp  is  greater  (more 
recent)  than  th€  timestamp  on  the  data  items  at  the  node. 
The  concern  with  this  approach  is  the  storage  burden  created 
by  the  timestamp  being  appended  to  every  data  item.  A  time- 
stamp  for  every  reccrd  versus  data  item  effectively  cuts 
3t.orage  require  lents ,  bu*  some  needless  conflicts  are 
incurred    and   som'=   updates   are   delayed    with    this    approach. 

The  Department  of  Defense  has  contracted  with  Computer 
Corporation  of  Airerica  (CCA)  to  investigate  -he  feasibility 
of  utilizing  distributed  database  -^.echnology  for  command  and 
control  situations.  CCA's  result  has  been  the  development 
of  the  system  for  Distributed  Database  (SDD-1)  which  appears 
to  have  elegantly  solved  the  concurrency  control  problem. 
As  this  development  has  generated  much  interest  in  the 
research  field,  a  brief  description  is  provided  in  Appendix 
E  which  provides  insight  to  net  only  the  concurrency  problem 
in  distributed  database  technology,  but  also  the  technical 
problems   of  query   processing   and   reliable   writing. 

Research  is  en- going  in  this  area  and  much  work  has  to 
be  done  before  it  can  be  effectively  used  by  an  organization 
that    is   not    technologically    sophisticated. 

F.       SUHHAHY 

Th€  requirements  into  the  foreseeable  future  will 
require  DBMSs  to  deal  with  higher  and  higher  transaction 
rates,  larger  data  bases,  and  more  complex  queries  to 
minimize  the  number  of  reports  received  ty  the  end  user. 
Fiqure  U.3  depicts  those  architectures  that  are  commonly 
available   today.      The   most    common   architecture   is    having   the 
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DBMS,  host  language  interface,  and  query  language  capabili- 
ties collocated.  Where  the  CPO  is  utilized  more  xhan  U5%  to 
perform  data  base  functions,  off-loading  the  DBMS  functions 
into  a  tack-end  processor  as  in  Figure  4.3  may  be  cost 
effective  [ Ref .  17].  But  this  is  only  a  partial  solution  to 
the    growing    requirements. 

The  technological        developments  in  associative 

processing,  very  large  scale  integration  (VLSI)  chips,  and 
database  machines,  will  make  architectures  like  Figure  4.4 
possible  with  much  better  cost/performance  ratios.  These 
configurations  are  not  commercially  available  today. 
Further  Coast  Guard  requirements  do  not  call  for  them  at  the 
present  time.  But  a  DBMS  strategy  must  recognize  that 
future  requirements  will  outsurip  what  is  available  today. 
Solutions  to  expanded  requirements  will  more  than  likely 
find  their  source  in  the  emerging  technology,  and  any  corpo- 
rate   strategy   must   take   cognizance   of   this. 
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V.  CORRENTLY  hl^LhA^LM    DBMS  ARCHITECTURES 

a.   GENERAL 

One  can  categorize  database  systems  by  the  form  of  the 
data  model  that  is  used,  e. g.  relational,  hierarchical,  and 
network.  The  primary  characteristic  of  a  relational  model 
is  that  all  information  in  the  database  is  represented  in  a 
single  uniform  manner,  namely  in  the  form  of  tables.  This 
data  model  supports  many-to-raany  relationships  of  data.  The 
characteristic  of  the  hierarchical  model  is  -^.hat  information 
is  represen-ed  by  a  simple  tree  structure.  Each  node  in  the 
tree  can  te  likened  to  a  single  file;  however,  these  files 
are  a  more  complex  object,  than  the  tables  of  the  relational 
model.  First,  the  file  may  contain  more  than  one  type  of 
record,  and  second  there  are  links  connecting  occurences 
(instances)  "of  these  records.  Hence,  the  data  in  a  hier- 
archical model  Is  represented  by  records  and  links  in  a 
one-to-many  relationship.  The  characteristic  of  the  network 
model  is  thar  information  is  represented  by  records  and 
links  as  in  the  hierarchical  model,  but  the  network  model 
has  the  capability  of  modelling  many-to-many  relationships 
like    the    relaticral    model. 

Since  the  difference  between  -he  network  (sometimes 
referred  to  as  CCDASYL  (Conference  on  Data  System 
Languages))  and  relational  approaches  to  DBMSs  are  such  a 
controversial  topic  at  the  present  time,  this  chapter  begins 
with  a  discussior  abcut  the  distinctions  between  the  CODASYL 
and  relational  approaches  to  database  management.  The  only 
goal  here  is  to  present  the  views  of  the  authors  and  what 
they  understand  the  difference  to  be  in  the  approaches. 
After   a   somewhat    lengthy    discussion   of    the   relational    versus 
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CODASYL  approaches,  a  discussion  of  a  particular  data  model 
from  each  of  the  three  current  available  DBMS  archit9ctures 
is  presented.  The  objective  is  to  provids  the  reader  with  a 
feel  for  what  each  data  m cdel  offers  -  its  strengths  and 
weaknesses  -  not  to  evaluate  all  DBMSs  available  on  the 
market  today.  A -^  the  end  of  the  chapter  the  consequences  of 
choosing  one  DBMS  architecture  over  another  are  discussed  as 
a  prelude  -o  the  next  chapter  on  a  database  management 
strategy. 

B.       RELATIONAL    A FD    CODASYL     NETWORKS 

To  understand  the  difference  between  the  relational  and 
CODASYL  (network)  approach  to  DBMSs,  it  is  necessary  to 
understand  the  three-level  hierarchial  view  of  a  data  base. 
The  Star.aaris,  Elanning  and  Requirements  Committee  (SPARC) 
and  the  American  National  Standards  Institute  (ANSI) 
published  an  interim  report  in  19'^5  defining  this  three- 
level  struc-ure.  The  programmers  view  of  data  is  referred 
to  as  the  external  schema.  The  overall  logical  view  or  what 
one  may  consider  the  corporate  view  of  data  is  called  the 
conceptual  schema.  Finally  the  physical  organization  of  the 
data    itself      is    ]<nown   as      the  internal    schema.  Figure    5.1 

depicts    the   three   different    levels. 

The  internal  schema  is  one  whose  records  are  manipulated 
by  READ,  WRITS,  and  DELETE  commands  of  COBOL  and  PL/I.  At 
this  level  one  notices  that  a  file  has  not  only  data,  bu-^ 
flag  and  pointer  fields  to  handle  overflow  in  a  hash  file. 
(There  exist  other  methods  tc  organize  the  data  physically; 
however,  for  purposes  of  illustration  the  file  under  discus- 
sion is  assumed  to  be  a  hash  file.  The  idea  of  a  hash  file 
organization  is  to  divide  the  records  cf  a  file  among 
buckets,  which  each  consist  of  one  or  more  blocks  of 
storage.         If  v    is    a    key   value,    h(v)     indicates   the    number    of 
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Figure   5.1        Three-Level    Hierarchy   of   a  DBMS- 

the  bucket  in  which  the  record  with  key  value  v  is  to  be 
found.)  At  the  concap+ual  schema  level  the  flag  and  pointer 
fields  are  of  no  interest;  in  fact  they  would  just  clutter 
the      file        with      meaninale ss        data      for        the      da-a        base 
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administrator  or  the  corporate  user.  At  +•  he  highest  level, 
the  ex-^ernal  schema,  each  programmer  or  user  is  only 
concerned  with  a  portion  of  the  conceptual  schema.  Thus 
external  files  and  the  fields  of  an  external  file  are  a 
subset  of  the  fields  of  the  underlying  conceptual  schema. 
The  ext<=rnal  schema  contains  no  flags  or  pointers  from  the 
internal  schema,  only  data  of  interest  to  the  data  base 
administrator  or  corporation.  It  should  be  pointed  oux  that 
the  fields  in  the  external  file  may  be  derivable  from  th« 
conceptual    schema.  As   an    example      the   field    'age*       in   the 

external  schema  is  derivable  from  the  field  'date-of-birth* 
in   the      conceptual    schema.  .(Note      these   are      two    different 

data  elements;  one  is  prcbably  represented  as  '480605* 
(conceptual  schema)  and  the  other  as  • 3U »  (external 
schema)  )  . 

There  are  s  c  iie  iirportant  consequences  flowing  from  this 
type  of  design.  If  for  some  reason  the  database  became  used 
heavily  for  sequential  access,  reads  and  writes,  it  should 
be  possible  to  change  the  internal  schema  without  affecting 
either  the  data  base  administrator's  view  or  use  of  the 
data.  Also  the  programmer  or  user  (the  external  schema) 
should  net  become  embroiled  or  tangled  with  changes  made  at 
the  internal  schema  level.  This  is  commonly  referred  to  as 
physical  data  Independence.  Another  closely  associated 
concept  is  loaical  data  independence.  Here  programmer  E  can 
add  another  field  to  his  external  schema.  If  the  field  is 
in  or  can  be  derivable  from  the  conceptual  schema  then  not 
much  effcrt  is  required  tc  provide  Programmer  B  with  the 
desired  field.  Eowever,  if  a  field  is  requested  that  is  not 
in  the  conceprual  schema  then  the  conceptual  and  internal 
schemas    will   have      some    work   to    do.  Logical   data    indepen- 

dence is  achieved  when  programmer  A*s  application  is  not 
affected  by  th€  changes  required  to  make  a  new  field 
available   tc   Procrammer      B.         The   benefits    that      follow    from 
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physical  and  logical  daria  independence  are  lower  mair.-^r.anca 
cost,  and  less  programmer  time.  Beth  the  relatiorial  and 
CODASYL    data    models    have   embraced   the    three-level    concept. 

The  core  of  understanding  the  difference  between  these 
data  models  lies  in  the  conceptual  schema.  One  can  view  the 
conceptual   schema  three   ways: 

1.  The    same  as   the    internal   schema    without    its    implemen- 
tation  of   flags    and   pointers. 

2.  A   common   derominator  logical  file    for    all   users. 

3.  A  collection      of  conceptual      records,      each      of    which 
describes    ar  entity   of    the    real    world. 

In  the  relational  mcdel,  a  relation  (table)  is  the  same  as  a 
conceptual  schema  in  which  no  two  records  (sometimes 
referred  to  as  tuples)  are  the  same  (i.e.  no  duplicate 
records).  Further,  a  relation  can  be  displayed  as  a  two- 
dimensional  matrix,  where  a  row  of  the  matrix  is  unique  and 
corresponds  to  a  record.  (It  is  important  to  realize  that  a 
relation  cannot  te  compared  with  a  conventional  file  as  the 
file  is  a  storage  file  that  physically  exists.  This  is  not 
so  with  the  relation  which  can  only  be  understood  in  terms 
of  conceptual  scl:eraas.)  Just  because  a  relation  is  equiva- 
lent to  a  conceptual  schema,  where  no  twc  records  are  the 
same,  does  not  mean  that  there  exists  conceptual  schemas 
that      are   not      r€lations.  For      instance,      any      number      of 

repeating  groups  or  fields  can  exist  and  are  permi-ted  in  a 
CODASYL  conceptual  schema.  If  -here  are  repeating  groups  or 
duplicate  records  in  the  conceptual  schema,  then  the  concep- 
tual schema  is  not  a  relation.  Hence  the  underlying 
difference    between    the  two    approaches. 

The  conceptual  schema  of  the  relational  model  imparts 
simplicity  as  external  schemas  derived  from  conceptual 
schemas  are  also  relations.  Further,  the  simplicity  of  the 
relational*  s  external  schemas  make  them  easy  and  convenient 
to   manipulate      via   application    programs.  The   relationship 
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between  the  ccnceprual  matrices  are  no-^  explicitly  specified 
(i.e.  ranted)  i  r.  the  conceptual  schema  for  a  relation,  the 
specification  of  the  connection  fields  supporring  the  rela- 
tionship being  necessary  and  sufficient.  For  example  it  is 
the    connection    fields  OPS  CNTL   in   AREA    COMMANDER    and   OP    CNTL 


10PS_CNTL  I  HQ  I 

ILANTAREA         |       New    York  | 

IPACAREA  I    San   Francisco  | 

AREA    COMMANDERS 


SFIP    NC 

OPS    CNTL 

SHIP_TYPE 

Wi»GB-10 

P ACAREA 

ICEBREAKER 

WAGB-11 

PACAREA 

ICEBREAKER 

WFEC-716 

L ANTAREA 

1        HEC 

WBEC-721 

LANTAREA 

HEC 

WFEC-723 

PACAREA 

HEC 

WJ?EC-618 

LANTAREA       | 

MEC 

WffEC-620 

P  ACAREA 

1        MEC 

VESSELS 


Figure   5.2        Example    of  Two    Relations. 

in   VESSEL   from      Figure   5.2    that    determines      the   relationship 

between    the   two    conceptual    matrices.         This    does    create   some 

difficulty      when    designing      a      retrieval      language    which      is 

sui-able    for   the   nonmathema tical    user.       Consider: 

SELECT    FEOM    AREA    COMMANDER    WHERE 
OPS    CKTL    IS    ITT 

1S5LECT    OPS    CNTL    FROM    VESSEL 

WHERE    SrTlP_TYPE    =    •ICEBREAKER*) 

Here      one    is     asking      for      the    AREA_COMMANDER      record      whose 

OPS_CNTL      field    values      from    VESSEL      records      for    which      the 

SHIP_TYPE    is    ICEBREAKER.      Very   convoluted  to    say   the    least. 
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In  contrast,  in  CODASYI,  the  files  of  -^.he  external  and 
internal  schemas  can  become  very  difficult  to  manipulate  via 
external  programs  if  the  records  of  the  schemas  contain 
varying  numbers  cf  repeating  groups  of  fields.  The  under- 
lying reason  is  that  the  data  structures  are  allowed  to 
vary.  In  a  CODASYL  conceptual  schema  the  records  are  typi- 
cally grouped  in  two  distinct  ways.  First,  records  of  the 
same  type  are  grouped  together.  This  grouping  is  similar  to 
the  grouping  of  tuples  (rows)  in  a  relation;  however,  the 
CODASYL  files  that  make  up  the  conceptual  schemas  don'^.  have 
to  be  relations,  i.e.  may  contain  r<=-peating  groups.  The 
second  method  of  grouping  is  into  owner-coupled  sets.  In  a 
set  based  on  two  files  like  in  Figure  5.2  each  owner  record 
is      grouped      with      i-s  member      record      giving     the      grouping 


|OPS_CNTI|       HC 

I- 

11 
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<->SHI?_NO    |OPS_CNTL    SHIF_TYPE 


ANiaHEAl  New 
I  New 
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i  San 
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I  San 
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York  <->WHEC-716 ILANTAREA 

York  <->WHEC-721 I LANTAREA 

York  <->WMEC-618 ILANTAREA 

Francisco<->WAG3-10  JPACAREA 
Francisco<->WAGB-11  1PACAREA 
Francis co<->WHEC-723  jPACAREA 
Francisco<->WMEC-620 | PACAREA 
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MEC 

MEC 
ICEBREAKER 
ICEBREAKER 

HEC 

MEC 


AREA     COMMANDERS 


VESSELS 


Figure    5.3        Owner-Coupled   Set   Occurrence. 

depicted  in  Figure  5.3.  The  relationship  between  the 
records    cf   -^he      -^wo    files   is   clear.  CODASYL  requires    that 

this  grouping  in  Figure  5.  3  be  given  a  name  in  the  concep- 
tual schema.  The  CODASYL  query  could  be  expressed  in  terms 
like; 
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Herreive  rhs  owner  record  of  each  owner- 
coupled  set  cccurance  in  which  all  but 
cne  of  the  member  records  have  a  SHIP  TYPE 
value    equal    to    ICEBREAKER. 

Hence,  as  the  relational  approach  asserts  that  groupings  of 
files  is  not  necessary  in  a  conceptual  database,  CODASYL 
requires  it.  Per  the  non -mathematican  certainly  CODAYSL's 
grouping    is   easier   to   comprehend. 

In  summary  then,  relational  databases  require  a  unique 
key  for  every  record  type,  a  means  of  representing  set  type 
relationships,  and  propagation  of  prime  keys  down  the  struc- 
ture [Ref.  18],  The  propagation  of  prime  keys  down  the 
structure  makes  it  very  difficult  for  the  user  to  form  a 
correct  query  via  the  retrieval  language  of  the  database 
system.  In  coritrast  CODASYL  does  not  force  a  data  base 
designer  to  propagate  prime  keys  down  the  structure;  thus 
allowing  English-like  queries  on  the  database.  However, 
there  is  nothing  in  CODASYL  to  prevent  conceptual  files  from 
being  designed  vith  repeating  groups,  duplicate  records, 
etc.,  thus  creating  data  structure  problems  in  the  future 
when    struc-^ures    have    to    be    changed. 

C.   RELATIONAL  -  SYSTEM  R 

On  30  January  1981  I  EM  announced  a  produc-  called 
SQL/Data  System.  This  system  is  a  relational  DBMS.  To  the 
users  of  SQL/DS  the  data  in  the  data  base  appears  to  be 
structured  in  -^-he  fcrm  of  tables.  The  SQL/DS  DBMS  is  the 
result   of    IBM's    v»ork    on    the    prototype    System    R. 

1 .      Capabili ties/Charac  teristics 

Seme  of  the  claimed  capabilities  of  SQL/DS  are  auto- 
matic navigation  through  the  data  base  and  automatic 
optimization.  The  user  of  the  DBMS  specifies  what  -^ihey 
want,         not      how      to      get   to      the      data      they      want.  This 
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description  of  'how'  is  performed  by  the  very  high-level 
language,  SQL.  This  language  has  the  ability  to  manipulate 
collections   of   records      not    just    single    records.  SQL   also 

acts  as  a  host  language  interface  to  COBOL,  PI/I,  and 
Assembler,  i.e.  SQL  statements  can  be  freely  mixed  with 
source   statements      from   COBOI      and   PL/I.  Besides    being      a 

guery  language  SQL  encompasses  data  definition,  bulk 
loading,  updating,  granting  authorization,  and  database 
recovery.  The  goal  of  automatic  optimization  is  achieved  by 
allowing    the   user   to    dynamically    change    an    index    or    key. 

5QL/DS  appears  to  support  the  American  National 
Standards  Institute  ANSI  X3  SPARC  study  group's  interim 
report  on  the  three-level  hierarchy  view  of  a  DBMS.  This 
recommendation  is  that  a  DBMS  should  support  an  external 
view  of  the  data  base  which  insulates  the  details  of  the 
physical  organization  of  the  data  base  from  the  logical  view 
of  the  data.  This  should  in  turn,  insulate  the  overall 
logical  structure  of  the  data  base  from  the  programmer  or 
user. 

As  in  most  DEMSs,  SQL/DS  provides  for  data  security 
via  access  control/authorization,  concurrency  control  for 
both  batch  and  interactive  processing,  recovery,  and  direc- 
tory management.  System  resources  consumed  depend  on  the 
complexity  of  the  data  base  and  the  nature  of  the  transac- 
tions; however,  it  is  claimed  by  IBM  that  performance  can  be 
kept    to    within   acceptable   limits. 

2 .      Critique 

During  t be  past  decade  there  has  been  much  research 
and  discussion  about  relational  databases  as  the  result  of 
the  papers  and  theoretical  work  done  by  Dr.  Edgar  F.  Codd. 
But,  the  number  of  commercially  available  relational  DBMSs 
is  rather  limited.  Table  V  and  Table  VT  provide  a  compar- 
ison between   three  (3)    commercially  available   relational 
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TABLE    V 

! 

Data   Definiticiir 

Manipulation, 

and    Control 

Facilities 

Fia«tura 

SQVtS 

OMCLB 

INGRES 

Okta  Oaflnition  Support 

Variabla  Length   Rows 

YM 

Ym 

Yes 

Null  Values  Supported 

Yes 

YM 

NO 

Oynamically  Add  New  Coluons 

Yaa 

Yes 

No 

Support  Stared  Oommands 

YM 

Mo 

NO 

Oynanuc  View   Definition 

yes 

Yes 

Yes 

Automatic  Elimination 

Of   Duplicate    Rows 

Optional 

Optional 

Yes 

Dynamic   Data  Base   Expansion 

Yes-Utility 

Yes-Utility 

No-O/S  Function 

Data  Manipulation   Support 

Storage   of   View   Text 

Yes 

Yes 

Yes 

Append  Table    to   Itself 

No 

NO 

Yes 

Support   for  User  Files 

Ho 

No 

Ho 

Specify  Disk   the  Table   is 

To   3e   Placed  On 

Yes 

No 

No 

Maximum  Size   Char.    Field 

32767        , 

Yes          \ 

255 

255 

Define   Synonyms 

No 

Mo 

Sort  Query   Results 

Yes 

Yes 

MO 

Data  Conversion   Functions 

^to 

NO 

Yes 

Help   Facility 

Yes 

No 

Yes 

Integrity  Constraints 

No 

No 

Yoe-Sinqle  Table 

Three-Walking   Syntax 

No 

Yes 

No 

Outer-Join   Syntax 

No 

Yes 

No 

Data  Control   Facilities 

Access  Permission   for  Tables 

, 

and  Views 

Yes 

Yes 

Yes 

Permission   Structure 

Decentralized 

Decentralized 

Centralized 

ttasource   Authorization 

Ves 

No 

No 

Password   for  Data  Base   Access 

Yes 

Yes 

NO 

datatases  [  Ref .  19]«  It,  is  apparent  that  these  three  (3) 
systems  provide  a  level  of  capability  to  support  the  Coast 
Guard's  requirements;  however,  because  they  are  relatively 
new  products,  items  such  as  vendor  support,  documentation, 
and   user    satisfaction  cannot    be    determined. 

D.       NETliCBK   -    COTASII   TYPE    -    TOTAL 

One  cf  the  irost  popular  DBMSs  on  the  market  today  is 
Cincom*s  Systems,  Inc.  -  TOTAL.  They  claim  over  3,000  users 
of  their  DBMS.  TOTAL  supports  the  network  data  model  by 
allowing    a    large   number   of    files   to   be    linked   together. 
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TABLE    71 
CoBpariscn   of    General   Capabilities 


Indax  Support 

Primary  Index  Required 
Support  Dynamic   Index  De£. 
Support  Multicolumn   Indsjcas 
Support  Variable   Length  Kays 
Physical  Ordering  of  Oaca 

(Clustering) 
Change   Clustering   Index 

Ladling 

Levels 

Automatic   Lock   Escalation 
Storage   Statistics  Aval labia 

'Optimization 

Access  >tethod 

Path  Selection  Methods 

t 
Transaction  Management 

Mult.    Statement  Transactions 
User- Con trolled  Backout 
Support  Nested  Transactions 
Disk   Recovery   Techniques 

Host  Language   Interface 

Type 

Languages  Supported 

Support  for  Multiple  Cursors 

Computer  Environment 

CPUs 

Operating  Systems 


SQL/DS 


No 
yes 
Yes 
Yes 

Yes 
No 


Row , Page , Tab le , 

Data  Spaca 

Yes 

Yes 


Compiled    , 
Evaluate   Indaxets ,   Scans 
and  TWO  Join   Methods 


Yes 
Yes 
No 
Roll   Forward   &  Backout 


Precompiler 
PL/I,    Cobol    and 
Assembler 
Yes 


43XX,370,303X 

VSE 


ORACLK 


INGXES 


VM 

NO 

HO 

Ye* 

NO 

Yes 

Yes 

Yes 

Only  on  Initial  Load 

Only  on  Initial  Load 

No 

Yes 

ROW, Table 

Table 

No 

No 

No 

Yea 

Interpretive 

Interpretive 

Evaluate  Indexes 

Evaluate  Indexes, Scans 

and  One  Join  Method 

Yes 

No 

No 

Yes 

Yas 

N/A 

Roll  Forward 

None 

Call 

Call 

Fortran, Cobol, PL/I 

Pascal  &  'C 

'C  and  Assembler 

Yes 

No 

POP  11/XX,  VAX 

VAX 

RSTS.RSX-llM.IAS,  Unix, 

VMS 

VMS 

1 .      Capab  ili;^ieg/Charac  teri  sti.c3 

Multiple  phases  ara  required  to  produce  TOTAL'S 
DBMS.  First,  data  tase  generation  is  necessary.  This  is 
done  hy  describing  files,  file  relationships,  data  elements, 
physical  file  characteristics,  and  buffer  usage  via  the 
high-level  Data  Ease  Definition  Language  (DEDL)  .  After  data 
and    files   have   b€en    formatted  the   Data    Manipulation   Language 
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(DML)  statements  can  be  embedded  in  a  hosz  language  to  begin 
actual      processing   of      data.  Access      to    the      database      is 

possible  via  FORIRAN,  COBOL,  FL/I,  RPG  II,  and  Assembler.  A 
simple      guery      language,         T-ASK,  and     report      generator, 

SOCRATES,  is  provided,  but  SOCRATES  can  only  be  executed  in 
batch   mcde. 

Ccmmmon  features  found  in  other  DBMSs  are  also  found 
in  TOTAL.  One  example  is  that  new  applications  and  files 
can  be  added  to  an  existing  data  base  or  a  new  relationship 
can  be  defined  for  existing  files  without  impacting  previ- 
ously implemented  applications  and  programs.  TOTAL  provides 
for  integrity  through  i-s  automatic  recovery  system  which 
restores  the  da-a  base  to  its  original  condition  pricr  to 
the  computer  system  cr  program  failure.  Password  prorecrion 
is  provided  at  the  file  level.  TOTAL  supports  both  interac- 
tive and  batch  processing.  Inconsistent  updating  is 
prevented  via  th=  use  of  record  locking,  i.e.  when  updating 
(writing)  a  record,  ether  processes  are  denied  access  to  the 
record. 

2 .      Critique 

TOTAL  is  popular,  and  can  be  run  on  many  machines. 
It  does  not  fully  support  the  three-level  hierarchy  view  of 
ANSI    X3      SPARC,       specifically  the      external   schema.  It    is 

capable  cf  handling  large  amounts  of  data.  There  are  a 
number  cf  versiors  of  TOTAL  which  are  supported,  i.e.  Basic, 
Extended,        Central,      and      Multithread.  The  Extended      and 

Central  versions  do  not  have  fully  re-entrant  code,  thus 
making  the  systems  a  bir  slow  in  a  multiprogramming  environ- 
ment   where    multiple    I/O's  are  handled. 

Table  VII  represents  a  1979  Datapro  survey  of 
proprietary  software  users  and  their  reaction  to  TOTAL 
[Ref.  20]-  From  the  table,  TOTAL  is  in  general  a  popular 
DBMS,    and    could    support    the    Coast  Guards'    requirements.         It 
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TABLE    VII 

—  — t 

197S  DataPro  Survey   of   TOTAL    0 

sers 

TOTAL   Larg 

e    Scale    Sy 
Excellent- 

stems : 

Overall   satis  facticn 

Good 

Fair 

Poor 

W.A. 

30 

51 

5 

1 

3.3 

Throughput/ef ficiency 

20 

48 

17 

2 

3.0 

Ease   cf    installaticn 

26 

41 

17 

3 

3.0 

Ease   cf    use 

25 

50 

12 

0 

3.2 

Documentation 

1U 

41 

27 

5 

2.7 

Vender   technical    support 

18 

36 

26 

7 

2.8 

Training 

10 

38 

22 

10 

2.6 

1 

TOTAL   Minicomputer   Sy 

STsms: 

1 

j 

Overall    satis  taction 

Excellent 

Good 

Fair 

Poor 

W.  A.        1 

12 

19 

4 

0 

3.2       1 

Throughpu-/ef  ficiency 

1 

27 

7 

0 

2.8       1 

Ease   cf    installaticn 

14 

17 

4 

0 

3.3 

Ease    cf    use 

10 

16 

9 

0  . 

3.0 

Documentation 

5 

17 

10 

3 

2.7 

Vender   technical    support 

10 

14 

8 

3 

2.9 

Training 

6 

16 

8 

3 

2.8 

is   worthy      to   no-^e      that    TOTAL      runs   on      many   minicomputers, 
e.g.      Prime    350-750,    PDP-11,    VAX-11,    and    others. 

E.       HIERARCHICAL    -    SYSTEM    2  000/80 

System  2000/60  supports  a  number  of  computer  systems  and 
operating  envirorments,  and  handles  hierarchical  tree  data 
base    structures.  The    system    was      first    introduced      by    MRI 

Sysrems   Corporation    in   1970.        In    1979,      MRI   was    acguired    by 
Intel   Ccrpcratior.  An   interesting      feature   is      that    Intel 

provides    a    Data    Ease    Assist    Processor     (DBAP)       which    incorpo- 
rates  the      Intel   semi-conductor      disk    unit,      with   the      System 
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2000/80  database  management  system.  This  is  a  varia-ion  of 
the    database   machine    mentioned    in   Chapter    IV, 

1 .  Capabili ties/ Charact eristics 

An  Integrated  Data  Dictionary  (IDD)  supports  System 
2000/80  vis-a-vis  maintaining  information  about  the 
processing  environment.  An  English-like  query  language, 
QUEST,  is  provided  to  generate  reports,  and  a  report  writer 
is  available  fcr  sophisticated  batch  report  generation 
requirements.  A      Programming      Language      Extension       (PLSX) 

allows  commands  to  be  embedded  in  host  programming  languages 
like  FORTRAN,  COBOL,  PL/I,  and  Assembly  Language;  this 
allows    further    processing   of    data   from    the    data    base. 

System  2000/80  supports  both  batch  and  interactive 
processing.  Also    jcurnaling,        rollback,      recovery,         and 

security    are      standard    features    of      the    DBMS.  Security    is 

provided  for  at  the  daza  base,  record,  or  item  level  by 
restricting  accesses  to  update,  retrieval,  or  search. 
Finally,  sixty-three  command  streams  can  be  handled  concur- 
rently  and    interleaved  at   the  I/O    level. 

2 .  Critique 

System  2C00/80  runs  on  many  machines  and  environ- 
ments including  IBM  360,  37  0,  303x,  and  4300  series;  Qnivac 
1100  series;  and  CDC  6000/Cyber  Series.  Boolean  logic  capa- 
bilities make  it  amenable  to  ad-hoc  queries.  The  biggest 
drawback  is  that  it  is  not  available  on  minicomputers  and  it 
requires  180K  bytes  or  more  of  main  memory.  The  results  of 
a  DataPrc  survey  [Ref.  20:  p.  70E-526-01b]  are  provided  in 
Table  VIII.  In  general.  System  2000/80  can  support  Coast: 
Guard's  requirements,  except  for  the  minicomputer 
requirement. 
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TABLE    VIII 
DataPro   Survey  of   System   2000/80    Users 


Excellent    Good   Fair    Poor    W.A, 


Overall    satisfaction 

Throughput/ef  ficisncy 

Ease   of    installation 

Ease   of    use 

Documentation 

Vendor   technical    support 

Training 


12 

15 

3 

0 

3.3 

3 

16 

11 

0 

2.7 

5 

11 

7 

0 

2.9 

11 

13 

6 

0 

3.2 

6 

15 

8 

1 

2.9 

9 

15 

3 

0 

3.2 

11 

14 

0 

0 

3.4 

P.       SDMHAHY 

In  general  any  BEMS  from  one  of  the  three  daza  models 
can  support  the  Coast  Guard's  requirements.  These  require- 
ments are  detailed  in  Chapter  VI.  The  drawback  of  the 
hierarchical  data  model  implementation  is  their  memory 
requirements.  IBM's      IMS     (IBM's      hierarchical    DBMS),         and 

Intel's  System  2000/80,  mentioned  previously,  cannot  be 
implemented      on    irini computers.  Ease      of      use    is      somewhat 

limited  tecause,  once  the  conceptual  schema  is  defined,  it 
becomes  very  difficult  to  modify.  Also,  the  conceptual 
schema  must  be  many-to-one  and  there  are  many  applications 
which  do  no-^  fit  this  mold.  On  the  positive  side,  the  hier- 
archical data  model  effectively  supports  very  large 
centralized  data  bases,  where  efficient  implementation  is 
the   constraining   factor.  This    data    model    also,         has    been 

used  for  a  decade  in  both  industry  and  government  with  some 
success;  hence  there  is  a  lot  of  knowledge  about  its  use  and 
implementation. 
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The  network  data  nodal,  unlike  the  hierarchical  data 
model,      can      be    implemented    on    minicomputers.  The    network 

data  mocel  does  support  large  data  bases  efficiently.  This 
model  too,  has  teen  in  existence  for  better  than  a  decade. 
The  problem  for  an  unsophisticated  user  is  the  implementa- 
tion details  that  must  be  known  to  use  the  DBMS.  Access 
paths  and  the  physical  data  organization  must  be  defined 
prior  to  use  by  the  implementor.  Although  the  data  model 
supports  many-to-many  relationships  of  data,  it  is  done  only 
with    difficulty. 

The  relational  data  model  is  relatively  new  and  based 
upon  the  theoretical  papers  of  Dr.  Codd.  There  are  not  many 
commercially  available  relational  DBMSs  in  existence  today. 
Because  of  this,  what  is  kncwn  about  the  relational  model  is 
restricted  to  the  research  laboratories  and  the  academic 
environment.  The  relational  models  that  do  exist  support 
small      and    medium      sized   data      bases.  The   exceptions      are 

ORACLE,  INGRES,  and  SQL/DS.  Implementation  of  large  data 
bases  are  usually  plagued  with  performance  problems.  On  the 
positive  side,  the  relational  models  are  easy  to  use,  i.e. 
the  conceptual  and  external  schemas  can  be  modified  easily 
to  fit  any  situation.  This  makes  it  ideal  for  supporting 
Decision  Support  Systems  (D SS) .  Undoubtedly,  the  relational 
model  will  play  a  more  and  more  important  role  in  the 
future.  First,  more  will  become  known  about  them  as  they 
are      implemented      commercially.  Secondly,        most      of      the 

research  at  universities  and  R5D  centers  are  concentrating 
almost   exclusively    on   the  relational    model. 
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?I.    DATABASE    MANAGEMENT    SYSTEM    STBATEGY 

A.       GENERAL 

This  chapter  will  present  a  broad  strategic  plan  for  the 
Coast  Guard's  us«=  and  implementation  of  a  database  manage- 
ment system  (DBMS).  To  help  motivate  this  scenario,  the 
Coast  Guard's  present  situation  is  outlined  followed  by  a 
short  discussion  of  their  planned  growth  in  the  database 
technology  arena.  Items  such  as  goals,  database  management 
system  reguireraents,  data  dictionaries,  migration  paths,  and 
approaches  are  discussed.  It  is  the  authors'  belief  "^.ha"- 
for  the  iiplemertaticn  of  any  strategy  the  Coast  Guard 
employs,  the  technology  must  be  commercially  available  and 
have  proven  itself  ever  the  past  few  years.  The  Coast  Guard 
can  ill  afford  tc  tackle  some  of  the  state-of-t he-ar*  -tech- 
nology with  its  meager  re'sources.  However,  the  actions 
taken  today  will  have  an  impact  on  -^he  Coast  Guard's  ability 
to  use  new  *echnclogy  later  when  tz  becomes  available  on  the 
market.  A  wrong  decision  today  could  effectively  lock  the 
Coast  Guard  out  cf  very  promising  alternatives  in  the  future 
years.  What  follows  are  the  authors  opinions  about  how  to 
achieve  a  database  management  system  technology  today  in  the 
Coast  Guard  without  locking  the  Coast  Guard  out  of  the 
changing   technology. 

1  •      iI^§§ILi    Situation 

ft 

All      strategies   must     begin      with      an   inventory      and 
evaluation      of   the      present    situation.  Clearly   the      Coast 

Guard  is  behind  the  proverbial  'eight  ball'  in  the  ADP  envi- 
ronment. Even  with  the  Commandant's  attention  and 
reorganization      cf    Coast      Guard      Headquarters      to    provide      a 
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flag-rank      cffic€  to      oversee      and      direct    Coast      Guard-wide 
information   requirements,    there    is   still   a    long   way   to    go. 

To  date  the  Coast  Guard's  use  of  DBMSs  has  been 
rather  haphazard.  A  few  years  ago  the  Coast  Guard  bought 
Cullinane's  database  management  system,  IDMS,  for  Coast 
Guard-wide  use.  Because  there  were  no  Coast  Guard  users, 
IDMS  was  turned  over  to  the  Department  of  Transportation's 
Computer  Center  (TCC)  ,  Today,  if  the  Coast  Guard  would  like 
to  use  it,  they  have  to  pay  a  surcharge  for  both  the  use  of 
the  DBMS  and  the  TCC's  computer.  Most  applications  in  use 
today  are  using  file  structures  that  were  popular  in  the 
late  1960's  and  early  1970' s,  and  are  not  taking  advantage 
of  current  database  management  technology.  Probably  the 
most  representative  example  is  the  Standardized  Aids  to 
Navigation  Data  System  (SANDS)  [Ref.  5].  The  system  was 
developed  in  the  late  1960 »s  using  the  file  structures  of 
that  date,  i.e.  flat,  fixed,  sequential  access  record  struc- 
tures. As  a  result,  today  the  system  is  of  little  use  or 
benefit  as  the  data  cannot  be  changed  to  meet  -he  require- 
ments of  -^he  users.  As  an  aside,  SANDS  is  being  revised  to 
see  if  the  data,  collected  over  the  past  15  or  so  years,  can 
be  of  any  benefit.  The  one  bright  spot  in  this  picture  is 
the  development  of  the  Marine  Safe-^y  Information  System 
(MSIS).  Although  it  has  taken  over  ten  years  to  get  to  its 
present  state,  and  it  is  not  fully  implemented;  database 
management  technology  plays  a  pivotal  role  in  its  develop- 
ment and  implementation.  MSIS  uses  Cincom's  DBMS,  TOTAL. 
The  use  of  a  data  dictionary  allows  control  of  over  2500 
data      elements        throughout      the        system.  Also,  Civil 

Engineering    (G-ECV)         is   currently      developing   a      data    base, 
data      dictionary,  and      da-^a        directory      using        database 

technology   [Ref.    5:    p.    5-32  ]. 
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2.      Planned    Grow+h 

Headquar ter ' s  Offices  are  planning  new  systems- at  a 
phenomenal  rate.  A  glance  through  Commandant's  Tnstruc-^.  ion 
M5230.81,  Automated  Data  Processing  (ADP)  Plan,  provides  the 
interested  reader  with  the  size  and  scope  of  the  new 
efforts. 

The  most  ambitious  new  undertaking  is  the  'District 
Minicomputer  Project.'  It  is  the  intention  of  the  Commandant 
to  procure  minicomputers  and  place  them  in  each  of  the 
twelve  District  Offices  to  provide  an  expanded  ADP  capa- 
bility at  major  field  commands.  This  proiect  is  to  be 
incremently  developed  with  initial  atxention  being  focused 
on  identifying  and  responding  to  the  critical  information 
and  management  n^eds  of  the  District  Offices.  Phase  one  of 
the  proiect  is  to  perform  the  required  planning,  identify 
inf or ma'icn  needs,  conduct  a  feasibility  study  and  provide 
for  resource  decisions.  Phase  two  provides  for  the  develop- 
ment cf  specifications  and  standards.  Phase  three  initiai:es 
procurement  action,  performs  system  development,  conducts 
database  formula-^ion  and  test/integration.  Finally,  phase 
four  commits  the  system  to  operation  and  provides  for 
refinement  and  expansion.  This  project  is  receiving  top 
management  control  from  the  Office  of  Command  Control  and 
Communication  (G-T)  with  the  attendant  bureaucractic  control 
and   standardization. 

Cnce  it  is  fully  operational,  the  iyiarine  Safety 
Informa-icn  System  (HSIS)  will  provide  the  Coast  Guard  with 
its  first  fully  matured  Management  Information  System.  The 
Operational  Computer  Center  (OCC)  located  at  Governors 
Island,  New  York,  using  PRIME  750s,  besides  running  the 
Automated  Mutual-Assistance  Vessel  Rescue  System  (AMVER) , 
the  Computer-Assisted  Search  Planning  System  (CASP) ,  Ice 
Plot     (ICIPLCT)  ,         and  the   Enforcemem:      of    Laws      and   Treaties 
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(ELT)  database  (limited),  will  support  the  Hazard  Assessment 
Computer  System  (HACS),  the  Spill  Cleanup  Equipment 
Inventory  System  (SKIM)  ,  and  the  ELT  database  (expanded)  . 
Thus  Coast  Gueird's  near  term  future  requirements  will  more 
than  double  today's  present  capacity,  while  quadrupling  the 
number  of  progra ns  and  files  necessary  to  support  the  infor- 
mation  needs   for  the   rest   of   the   decade. 

B.       DBMS    OBJECTIVES 

A      database    management       system      must      address    the      basic 
issues   cf    (1)  the    organization    of   an      integrated    database, 

(2)  the  storage  locations  for  data  in  the  system,  (3)  the 
location  of  data  in  the  svstem,  (U)  the  control  of  concur- 
rent addresses,  and  (5)  the  mechanisms  and  structures  to 
provide  security  and  integrity.  Aside  from  the  DBMS  soft- 
ware, other  appendages  are  considered  necessary  -  a  data 
dictionary,  and  cood  software  for  interrogating,  searching, 
maintaining,  and  generating  reports  from  the  database. 
These  ~wc  items  will  be  discussed  later  in  the  chapter. 
What  follows  is  a  discussion  of  the  main  objectives/ 
requirements    that  a    DBMS    for   the   Coast    Guard   should  support. 

The  Coast  Guard  will  be,  in  a  majority  of  cases, 
developing  databases  by  subject  area  as  proposed  by 
[Ref.  10].  This  is  in  contrast  to  developing  data  bases  by 
application  areas.  Different  programmers  will  have  and 
require  different  conceptual  views  of  the  same  data.  As  an 
example,  if  '  0!^DER WAY_HO0RS'  were  in  a  data  base  called 
OPERATIONS,  then  a  programmer  for  Naval  Engineering  may  want 
to  use  this  data  element  with  the  » VESSEL_AGE« ,  and 
'LAST_RErATR_DAT 1'  to  determine  a  maintenance  repair 
schedule.  A    programmer      for  Operations      may      want    -^o      use 
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»ONDEEWAY_HCURS  »  from  the  database  OPERATIONS  along  with 
«STANEARr_DNDERWAY_HCORS',  and  ' AVAIL ABLE_VESSELS •  to  deter- 
mine deplcyment  schedules.  The  DBMS  must  be  able  to  support 
both  views  of  this  single  data  element.  Therefore  the  DBMS 
must  fce  able  to  derive  from  boxh  th?  data  and  logical  rela- 
tionship, the  logical  files  that  are  necessary.  Further, 
the  prcgraaiffler  should  not  have  to  be  concerned  with  how  the 
data  is  physically  shared.  Transparency  for  the  programmer 
is   the   main   concern. 

2<.      Perf  orma  r.ce 

The  Coast  Guard  will  have  requirements  for  both 
interactive  and      batch   processing  via      the    DBMS.  The    more 

complex  queries  and  reports  will,  in  all  likelihood,  be 
submitted  for  batch  processing,  while  the  relatively  simple 
ad-hoc  query  will  be  submitted  interactively.  Wilson-Hill's 
Report,  [Ref.  10:  p.  4-15],  indicates  that  approximately  90% 
of  Coast  Guard's  use  will  be  interactive.  It  is  not  unrea- 
sonable that  oth'tr  systems  will  have  a  similar  mix;  however, 
they  will  protably  no-  be  as  high  for  interactive 
processing.  Hence,  database  applications  designed  for  use 
by  a  terminal  operator,  and  queries  of  the  data  base,  must 
have  a  response  time  appropriate  for  man-machine  dialogue, 
i.e.  response  times  of  3  to  5  seconds  85%  to  90%  of  the 
time.      [Bef.    21] 

In  addition,  the  DBMS  must  be  capable  of  handling 
the    throughput.  Initiall y,      in    any      DBMS   whether      for   the 

District  Minicomputer  Project,  for  the  Operational  Computer 
Center  (CCC) ,  cr  for  one  of  the  'super'  minicomputers  at 
Coast  Guard  Headquarters,  the  throughput  will  be  relatively 
low.  As    a      mir.imuiD   each       'super'      minicomputer    should      be 

capable  of  supporting  150  users  with  20  concurrent  users. 
Since  these  are  the  requirements  determined  and  supported  in 
Wilson-Hill's      Report,        [Ref.    10:         p.         4-17],         it      seems 
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appropriate  that  this  be  a  basic  requirement  for  any  DBMS 
used  by  Ccast  Guard.  Needless  to  say,  if  an  applicaiion  or 
subject  area  data  base  requires  higher  performance  then  that 
should  be  the  level.  The  Marine  Safety  Information  System 
(MSIS)       is      one    such    except  ion.  This    system      provides    the 

upper  end  of  performance  throughput,  as  their  requirements 
are    for   over    250   users  with    up   to  50   concurrent   users. 

3.      H  inimiza  tion    of   Costs 

There  are  many  cost  features  which  interact  when 
considering  a  DBKS.  The  first  is  the  cost  of  the  DBMS  soft- 
ware itself.  Depending  on  the  features  in  the  DBMS,  the 
costs  may  be  rather  significant,  i.e.  $100,000  or  betrer  for 
its  purchase,  plus  a  monthly  maintenance  charge  as  a  DBMS 
software  package  is  usually  proprietary  property.  The  other 
consideration  is  that  the  purchase  price  may  only  be  for  one 
copy,  i.e.  for  the  District  Minicomputer  Project  -  12  copies 
may    have    to   be   purchased. 

The  largest  cos-,  the  one  usually  overlooked  or 
underestima-*-ed,  is  the  database  conversion,  loading,  and 
establishment  of  a  data  dictionary  system.  There  is  the 
cost  of  loading  say  a  'flat  '  COBOL  file  into  the  data  base. 
Also  there  is  a  cost  incurred  of  not  converting  or  loading 
COBOL  files  into  a  DBMS.  For  instance,  if  data  cannot  be 
converted  or  loaded  into  a  data  base,  then  the  information 
is  lost.  Therefore,  the  Ccast  Guard  has  a  decision  to  make 
whether  or  not  to  maintain  the  old  procedures  for 
capturing,  storing,  and  manipulating  this  data  or  cut  with 
the  past  and  start  anew.  This  maintaining  of  old  ways  is 
costly  in  prograimer  maintenance  and  data  entry  effort.  As 
such,  this  decision  shculd  be  considered  carefully. 
Installing  a  data  dictionary  system  is  not  an  easy  cask,  and 
the      cost    is     usually   in      terms      of  politics.  Individuals 

consider    data  to      be   their    cwn    property    and      not   a    corporate 
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entity   to      be   managed   as   such.  The    cost    is   the      effort    it 

will    take    tc      integrate   the    data    dictionary      system    into   the 
organization. 

These  short  term  costs  must  be  balanced  against  the 
long  term  costs  of  creating  addi-^,  ional  files,  changing 
logical  structures  fcr  different  programmers  or  applica- 
tions, and  the  overhead  required  for  data  searching  and 
storage  capacity.  Without  a  DBMS,  maintenance  programming 
becomes  prohibitively  expensive  in  just  a  short  time. 
Changes  tc  data  structures  or  logical  programs  cannot  be 
done  without  raa":or  disruption  to  other  programs  and  data. 
There  comes  a  tine  where  one  scarifices  performance  require- 
lents  in  order  to  accommodate  new  requirements  in  the 
application.  In  the  case  of  reduced  requirements,  time  may 
have  to  te  degraded  as  the  volume  of  data  +o  be  retrieved  or 
updated   reaches    the    upper   limit    of   -^.he    capability    of    a    DBMS. 

^»      Minimal    Fedundancy 

The  impcitance  of  this  requirement  cannot  be  over 
emphasized.  Tr  is  at  the  core  of  what  database  management 
systems   are    all    about. 

A  data  base  may  be  defined  as  a  collection  of  interre- 
lated data  stored  together  without  harmful  or 
unnecessary  redundancy  to  serve  one  or  more  applications 
in  an  optimal  fashion;  the  data  are  stored  so  that  they 
are  independent  of  proara ms  which  use  the  data;  a  common 
and  ccntrolled  approach  is  used  in  addressing  new  data 
and  in  modifyirg  and  retrieving  existing  data  within  the 
data  base.  Ore  system  is  said  to  contain  a  collection 
of  data  bases  if  they  are  entirely  separate  in 
structure.      [Hef.    22] 

There   are      three   reasons      for   keeping      data   redundancy      to   a 

minimum.         First,      there      is    the    additional   cost      of    storing 

extra    data.         At   one   time  this   was    extremely    important,      but 

today      with   the      cost   per      bit      of   stored      data    dropping      so 

rapidly    it    is   becoming  less    of   an    issue.         The   second    reason 

is   the   reguiremert    tc   update   all   the    different   copies    of   the 

data.         As     a  result   of     duplicate   data,         computer   overhead 
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increases,  and  the  complsxi-^y  of  the  software  to  keep  track 
cf  the  duplicate  data  and  the  access  paths  increases.  The 
third,  and  probably  zhe  reason  most  managers  distrust 
computers,  is  that  different  copies  of  the  data  are  in 
different      updat€   states.  These      different   update      states 

produce  inconsistar.t  information  depending  on  the  access 
path  taken  by  th-r  DBMS.  However,  it  is  important  to  realize 
that  a  cer-^.ain  amcunt  of  redundancy  may  be  necessary  to 
improve  performance.  This  is  even  more  so  in  a  distributed 
type  environment  than  in  the  traditional  centralized  method. 
In  cases  where  redundancy  or  controlled  redundancy  is 
required  steps  must  be  raken  to  insure  concurrency  control 
or   synchronization    of   these    redundant    data    items. 

5.      Q^^Ll  ^Ik2  Report   Generation 

The  DBMS  shculd  provide  facilities  to  respond  to 
requests  that  ar€  net  anticipated  in  any  degree  of  detail  - 
i.e.  ad-hoc  queries.  Since  Coast  Guard  personnel  will  vary 
in  degree  of  computer  sophistication,  it  is  necessary  -^hat 
the  DBMS  provide  a  query  or  retrieval  language  that  is 
'English-like'  and  relatively  easy  to  use.  As  an  aside,  the 
reasons  DBMSs  have  caught  on  so  well,  is  their  ability  to 
extend  -he  power  of  the  'bare'  machine.  It  allows  both  a 
programmer  and  n cn-programm er  the  ability  to  manipulate  data 
without  having  tc  worry  about  things  like;  how  is  the  data 
stored,  what  is  the  access  path,  is  the  file  indirect 
sequential  or  the  other  many  details  which  do  not  help  the 
user    with   his    imirediate    immediate  task. 

The  types  of  queries  can  range  from  very  simple  to 
relatively  complex.  As  a  minimum,  the  query  must  be  able  to 
access  data  in  the  database  through  a  varie-*:y  of  methods, 
including  direct  and  Boolean  (logical)  connectors.  It  must 
be  capable  of  interfacing  with  other  system  capabilities 
like      application  programs      and      report      generators.         As      a 
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further  requirement  it  must  be  able  to  generate  a  query 
aqainst  temporary  files  and  support  several  users 
ccncurr'=ntly. 

The  repcrt  generator  must  be  flexible  enough  to 
support  a  variety  of  output:  formats,  and  interface  with 
application  programs.  The  language  should  be  easy  to  use 
(English-like) ,  logical,  and  should  be  able  to  process 
single  and  multiple  files  with  the  capability  to  build  and 
store   output    for   later  use. 

There  exists  commercial  report  generators  like  FOCOS 
and  RAMIS  II  which  can  be  procured  as  an  add-on  item,  if  not 
available    with    the    DEMS    software. 

6.      Inlf^rity  Controls 

The  DBMS  system  must  provide  routines  to  insure  that 
the  data  in  the  database  are  accurate  at  all  times.  One  can 
view  maintaining  the  integrity  of  a  database  as  protecting 
the  da-'-.a  against  invalid  (no!  illS^^l)  alteration  or 
destr  uc-^icn. 

First,  the  system  must  be  capable  of  checking  each 
individual  data  item  value  for  plausibili-*-y,  e.g.  the  hours 
a  vessel  is  underway  during  the  week  cannot  exceed  158.  In 
a  multi-user  system  the  loss  of  an  update  must  be  guarded 
against.  This  can  happen  when  data  are  shared,  and  one 
update  is  allowed  to  overwrite  the  other,  thus  nullifying 
the  first  update.  (Note:  In  some  systems,  allowing  several 
users  to  update  the  same  data  concurrently  is  a  requirement, 
ftn  airlines  reservation  system  where  it  is  important  net  to 
book    a   seat    more   than   once,    is   the   classic   example.) 

In  general,  loss  of  integrity  will  arise  as  a  result 
of  a  hardware  cr  software  failure  such  as  at  a  central 
processor,  data  channel,  o  r  an  inpu-^/output  device.  Human 
error  on  the  part  of  the  terminal  user,  programming  errors 
in   the   underlying  operating    sysrera,    or    programming   errors   in 
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the      5a+abase  application      will      also      adv€rsely   affec-      th-a 
integrity   of   the    data   base. 

Several  routines  should  be  provided  to  support 
system  integrity  such  as,  journaling  routines,  dump  rout- 
ines, recovery  routines,  backout  routines, 
checkpoint/restart  routines,  and  detection  routines. 
Journal  routines  record  every  operation  on  the  database  in  a 
systems  log  or  audit  trail.  As  a  minimum  the  audit  trail 
should  contain  an  identification  of  the  transaction 
concerned,  a  tiirestamp,  an  identification  of  the  terminal 
and  user  concerned,  the  full  text  of  the  input  message,  and 
the  type  of  charge  and  the  address  of  the  data  charged, 
together  with  its  before  and  after  values.  Dump  routines 
are  used  to  make  backup  copies  of  the  database;  usually  only 
selected  portions  of  -he  database  are  dumped.  Recovery 
routines  are  reguired  to  restore  the  database  to  an  earlier 
state  if  there  is  a  hardware  or  software  failure.  The  audit 
tape  will  be  used  as  input  to  this  routine.  Detection  rout- 
ines will  be  r^guired  to  search  for  any  violations  of 
integrity   contraints    before    -he    database    is   written   on. 

7 .      Security   and    Privac  y 

The  Coast  Guard  has  a  reguirement  for  both  security 
and  privacy  of  data.  Information  will  eventually  contain 
classified   data    and    confidential    personnel    information. 

Data  security  refers  to  protection  of  data  against 
accidental  or  intentional  disclosure  to  unauthorized 
persons,    or   unauthorized    modifications    or   destruction. 

Privacy  refers  tc  the  right  of  individuals  and  organ- 
izations zo  determine  for  themselves  when,  how,  and  to 
what  extent  information  about  them  is  to  be  transmitted 
to    ethers.      [Hef.    23] 

The    DEMS      must    b€      capable    of      positively   identifying      users 

(authentication)      before   they      are   allowed    to   use      the    DBMS. 

The   software   must      provide    access  control   •'■o      insure   ordered 

accesses    are   valid.         Transactions   must      be   capable   of   being 

monitored,    and   data    must   be    reconstructible    from    journals. 
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8-     I]3lJSrIi§^^l  Hi§i;^£2]il 

In  the  previous  chapter  there  was  a  reference  to  the 
American  National  Standards  Institute  ANSI  X3  SPARC  study 
group's  interim  report  regarding  the  three-level  hierarchy 
view  of  a  DBMS.  A  BEMS  must  support  this  conceptual  view  of 
a  database,  i.e.  internal  schema  -  (physical  view) ,  concep- 
tual schema  -  (logical  view) ,  and  external  schema 
(programmer's  view).  Each  schema  should  be  independent  from 
the   other   schema s;    in   other    words: 

1.  The  programmer  utilizing  the  external  schema  should 
be  provided  (by  the  conceptual  schema)  all  the  ir.for- 
ma-^-icn  required  to  use  the  external  schema  and 
IJOiiillH   mor  g. 


The    data   base   administrator      utilizing   the    conceotual 

__      ^_  - ,  jy      both       

schema   and    the    internal      schema)       all   the   information 


schema      should    ^ be      provided    (by      both      the      external 


required   to   logically    design  the    database   and   nothing 
more. 

3.  The  iirplementcr  of  the  internal  schema  should  be 
provided  (by  the  conceptual  schema)  all  the  informa- 
tion required  to  complete  the  imolemenTation  of  the 
internal    schema    and   nothing  lore.' 

This  type  of  construction  in  the  DBMS  provides  flexibility, 
and  ensures  maintainability  and  reliability.  Flexibility  is 
provided  because  changes  in  the  size  of  the  data  base, 
storage  of  the  data  base,  and  •  the  number  of  users,  can  be 
accommodated  up  to  the  limits  of  the  technology  imposed  upon 
the  system  i.e.  memory  size,  speed  of  CPU,  etc.  The  entire 
DBMS  should  be  irore  maintainable  as  those  items  that  are 
likely  to  change,  e.g.  the  s-^-orage  structure,  corporate  view 
of  the  data  and  programmer  use  of  data,  are  isolated  from 
one  another.  Hence,  changes  are  not  propogated  throughout 
the  entire  systei.  Because  the  entire  DBMS  is  more  maintai- 
nable, the  reliability  should  follow  as  a  natural 
consequence. 
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C.      CCAST    GUARD    INPOBMATIOM AL   GOALS 

Today  the  Coast  Guard  is  not  facing  the  complex  problems 
cf  other  organizations  who  have  many  years  of  data 
processing  experience  and  who  have  continuously  used  the 
state-of-the-art  technology  over  a  long  period  of  time. 
Basically  the  Coast  Guard  is  just  beginning  to  use  some  of 
the  newer  technology  available  today  -  database  management 
systems,  networks  i.e.  TELENET,  16-bi-^-  microcomputers,  etc. 
This  lack  of  experience  is  a  handicap;  it  provides  a  very 
small  knowledge  base  upon  which  to  draw  experienced 
personnel.  On  the  other  hand,  the  Coast  Guard  can  learn 
from  the  organizations  that  have  already  introduced  the  new 
technology,      lik€      DEMSs   and      distributed   processing.  The 

first  thing  that  is  discernible  from  organizations  that  have 
implemented  database  technology,  is  that  the  reguirements 
for  a  DEMS  are  easily  met  by  many  of  the  commercially,  avai- 
lable packages.  This  is  not  particularly  surprising, 
especially  as  the  reguirements,  although  difficult  to  imple- 
ment, provide  handsome  returns  in  the  market  sector  of 
society.  The  two  most  acute  problems  stem  from  managerial 
decisions.  On€  concerns  the  implementation  of  database 
management  -^.echnology,  while  the  other,  concerns  the  poli- 
cies to  keep  current  wit;h  computer  technology.  First,  an 
organization  will  inves-  a  great  deal  of  resources,  devel- 
oping applicatiors  using  COBOL  type  files.  The  organization 
finds  out  later,  they  cannot  take  advantage  of  new  tech- 
nology, e.g.  DBMS.  The  reason  is  there  is  no  economical  way 
to  convert  the  data  and  procedures  of  the  COBOL  oriented 
system  zc  a  DBMS.  The  second  problem  affects  the  federal 
government  probably  more  than  the  private  sector.  This  is 
concerned  with  the  upward  compatibility  of  resources,  i.e. 
computers,  operating  systems,  DBMSs,  and  secondary  storage 
devices.         Maragement     invests    heavily      in   current      computer 
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technology  only  ending  up  having  to  scrap  the  previous 
effort  to  take  advantage  of  the  newer  technology.  Today, 
management  is  no  longer  allowing  this  to  happen.  The  mark- 
eting strategies  of  the  computer  industry  recognize  this 
fact,  and  now  provides  f cr  upward  compatibility  of  new 
items.  An  exception  is  the  microcomputer  industry.  Thus, 
the  problem  reduces  to  determining  a  migration  path  for 
expanded  computer  system  requirements.  Therefore  the  goals 
of   a    DBMS    strategy    are: 

1.  To   provide      for   the   protection   of      the   organization's 
intellectual  development   and 

2.  To        provide        a        migration  path        for        expanded 
requirement  s. 

What    is    cf   concern    in   regards  to   goals    is   the   ability   to  not 

only      integrate    database      management      -technology    within      the 

organization,      but      to  insure  its     future   and  to      reduce  the 

turbulence   that    comes    from    follow-on   changes. 

1 .      Protecticn    cf   Intel lectual    Development 

Host  entities  utilize  a  DBMS  because  it  provides 
easier  access  to  data  while  allowing  the  programmer  to  spend 
his  time  writing  programs  to  manipulate  that  data.  Although 
this  is  a  very  desirable  feature  of  DBMSs,  it  is  not  the 
main  ccncern.  In  fact,  because  DBMSs  have  abstracted  the 
data  so  tha-^  it  is  closer  to  the  way  people  think,  an  enti- 
ty's data  base  can  be  allowed  to  grow  willy-nilly.  For 
example,  an  application  for  law  enforcement  is  determined  to 
be  extremely  valuable  for  the  organization.  To  help  with 
the  development  of  a  management  information  system,  the 
designers  and  implementors  decide  to  use  a  DBMS  to  organize 
the  data.  However,  the  data  going  into  the  data  base  is 
defined  and  utilized  by  only  a  small  fragment  of  the  organi- 
zation even  though  the  data  is  of  benefit  to  other  entities 
within   the    organization.         Without    too    much    trouble,    one   can 
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picture      what      happens.  The      other      entities      within      the 

organization  develop  their  own  management  information 
system,  defining  data  in  their  own  way  and  using  different 
DBMSs.  Before  long,  the  organization  has  a  proliferation  of 
data  wi-^h  much  duplication  and  inconsistency.  But  the  worst 
thing  is  that  there  is  no  w ay  t o  protect  the  data  and  proce- 
dures that  have  teen  developed  when  the  organization  either 
tries  to  consolidate  the  redundant  data,  to  reduce  bot-^le- 
necks      in      oerformance,  or      to     take      advantage        of      new 

technology,  like  a  back-end  processor  to  handle  DBMS 
funct  ions. 

An  cbvious  solution  is  to  centralize  everything  and 
have  all  th^  organization's  data  placed  into  one  big  corpo- 
rate data  base  tha-^  will  prcvide  the  manager  with  everything 
there  is  to  know  about  the  organization.  Many  companies  and 
agencies  have  tried  this  only  to  fail.  It  is  just  roo  big 
an   undertaking      for    most   large   organizations.  An   approach 

taken  frcm  software  engineering  is  to  modularize  the  process 
and  take  advantage  of  what  the  DBMS  software  provides. 
First,  try  to  minimize  the  effects  of  change.  For  example 
where  the  data  bases  are  developed  by  application,  a  change 
in  a  da-^a  element  resulting  from  a  law  or  regulation  will 
have  a  ripple  effect  throughout  the  organization.  However, 
if  data  bases  are  developed  by  subject  area  the  effects  of 
change  are  reduced.  Therefore,  one  way  to  help  insure 
protection  of  an  organization's  intellectual  development  is 
to  develcp  data  bases  by  subject  area  versus  application 
areas. 

To  help  implemenT:  subject  area  data  bases,  and  main- 
tain consistency  throughout  +-he  organization,  the  use  of  a 
data    dictionary      system   is    essential.  If  the      Coast    Guard 

requires  a  three-level  hierarchy  for  a  DBMS  in  each  subject 
area  then,  surely  at  the  conceptual  schema  level,  one  must 
know    what   the   entities   and    characteristics   of  those   entities 
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are  that  one  is  managing.  For  one  person  to  manage  500  or 
more  data  elemerts  without  some  kind  of  software  tools  is 
unthinkable.  This  is  a  conservative  estimate  of  the  number 
of  data  elements  that  will  comprise  a  subject  area  data  base 
[Ref-  10:  p.  3-i|].  In  short  what  a  data  dictionary  system 
provides    is   the    capability    for: 

1.  Specifying  the  type  of  an  entity,  such  as  a  form,  a 
data    element,    or  a    computer    file. 

2.  Uniquely  nairing  an  entity  and  describing  it  in  appro- 
priate terms,  such  as  the  range  of  values  of  a  data 
element   or    a  narrative    description   of    its   meaning. 

3.  Specifying    the    flow  and   the   storaae    locations   of    data 

entities      within     the      organiza-icn        or      within      the 
computer  installation. 

4.  Specifying  associations  and  relationships  among  the 
data  entities;  for  example,  appearance  on  the  same 
form,    or   derivation   of    an   entity    from    another. 


entities.  [Ref.  2U ] 
The  authors  believe  that  the  use  of  a  da^^a  dictionary  must 
he  a  requirement  and  the  burden  a  user  must  pay  in  order  to 
obtain   the    benefits    cf  a    DBMS. 

In  conjurcticn  with  a  data  dictionary  system  there 
exists  the  requirement  for  a  database  administrator.  The 
design  cf  the  conceptual  schema  will  normally  be  done  by  the 
database    administrator   and    a   staff.  Also   this    person   will 

be  responsible  for  the  implementation  of  the  conceptual 
schema  as  a  physical  data  base.  Once  implemented  the  data- 
base   administra t cr    performs    these  functions: 

1.  The    creation   of    subschemas    for   external   views. 

2.  The  gran tine  of  authorization  to  use  the  data  base  or 
certain   parts   of   it. 

3.  Modification  of  the  conceptual  schema  should  the 
original  design  prove  faulty  or  the  requirements  of 
the   organization   change. 

H.  Modificatior  cf  thf  implementation  of  the  conceptual 
schema  by  tire  physical  schema.  should  past  usage  of 
the  data  base  indicate  another  organization  of  the 
data   base    be   more  efficient. 
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5.  Makinq  backup  copies  of  the  data  base  and  repairing 
damage  (e.g.  'trashed  pointers')  'o  -he  data  base. 
[Ref.    25] 

One  should  not  underestimate  the  difficulty  of  this  task. 
Defining  a  conceptual  schema  to  accommodate  the  external 
views  of  multiple  users  is  no  easy  task.  In  fact,  most 
personnel  hired  as  database  administrators  leave  out  of 
frustration.  Ore  cannot  expect  this  position  to  be  filled 
by  a    junior      person    within    the   organization.  The    position 

requires  the  talents  of  a  project  manager.  He  must  have  the 
respect  of  the  organization,  and  a  fairly  in-depth  technical 
background  in  computer  science.  Although  this  is  an  impor- 
tant job,  -raditionally ,  it  has  been  either  underestimated 
in  its  importance,  or  ignored.  In  either  case,  the  effec- 
tive use  of  database  management  technology  has  been  minimal. 
The  Coast  Guard  must  be  willing  to  establish  this  posixion 
and  fill  it  with  highly  qualified  personnel  at  those  offices 
utilizing   database    management   technology. 

Whilethe  development  of  data  bases  by  subjec-^  area, 
and  the  use  of  data  dictionary  systems  will  help  provide 
seme  continuity,  it  will  not  insure  a  high  degree  of  protec- 
tion of  developed  data  bases.  If  those  data  bases  are 
allowed  the  choice  of  selecting  DBHSs  without  any  overall 
central  policy,  then  the  efforts  of  integrating  a  data 
dictionary  and  data  base  administrator,  will  fail.  Because 
the  policy  and  selection  of  equipment  for  the  District 
Minicomputer  Project,  is  a  Headquarters  controlled  under- 
taking, they  will  help  insure  the  protection  of  the 
intellectual  development  of  data  bases  at  different  District 
Offices.  Becaus€  the  District  Offices  are  somewhat  indepen- 
dent, responsible  tc  Program  Managers  at  the  Headquarters 
level  and  responsible  for  field  units  in  the  District's 
jurisdiction,  there  is  now  little  need  to  distribute  data- 
base management  systems  among  the  different  districts.  In 
fact    there    is   little    need  at     the    present    time  to    distribute 
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the  data  betweer  Districts.  Although  the  distributicn  of 
data  may  b€  desirable  in  some  cases,  the  communicat ion 
costSy  protocols,  conrrol ,  and  lack  of  technically  know- 
ledgeable person  r.el  make  t.his  a  high  risk  undertaking  at  the 
present  time.  The  risks  of  trying  to  distribute  both  the 
data  and  the  processing  among  districts  at  the  present  time 
outweigh  any  of  the  benefits.  However,  at  a  later  time  when 
the  distribution  of  processing  and  data  are  deemed  desi- 
rable, then  it  may  be  accomplished  without  wholesale 
disruption  of  past  efforts.  This  can  happen  only  if  the 
Districts  are  r^guired  to  use  predetermined  data  bases, 
based  upcn  subject  areas,  and  if  the  Districts  are  reguired 
to  use  the  same  commercially  available  DBMS  package. 
Therefore,  the  control  of  the  selection  of  DBMSs  and  the 
broad  definitior  of  subject  area  data  bases  should  be  a 
Headguarters  level  function.  It  is  important  to  note  that 
development,  implementation,  and  use  of  data  bases  is  a 
decentralized  function,  i.e.  the  responsibility  of  the 
District   Office    cr   the  Program   Manager. 

2 .      Growth 

There  are  two  fundamental  facts  about  data 
processing,  change  and  growth.  Costs  are  dropping,  machine 
structures  are  changing,  new  architectures  are  appearing. 
What  the  Coast  Guard  thinks  its  requirements  are  today,  and 
the  technology  to  handle  those  requirements,  will  not  be 
sufficient  tomorrow.  The  Coast  Guard  will  need  t,o  move  to 
new  systems  because  they  are  more  cost-effective;  however, 
the  Coast  Guard  cannot  re-write  the  multitude  of  old 
programs  because  there  will  not  be  enough  programmers.  The 
computer  industry  itself  has  recognized  these  two  facts  for 
years.  They  realize  they  cannot  design,  manufacture,  and 
market  equipment  so  that  it  stays  continuously  current.  The 
manufacturers  have      developed  a    strategy      to   allow      for   both 
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change    and    growth.  Both    operating   systems   and      the    'bare' 

machine  (processcr)  en  which  the  operating  system  runs  are 
developed  using  the  manufacturer's  strategy  for  handling 
change      and   growth.  An   initial      version      of  an      operating 

system  will  be  released,  and  as  new  technology  is  added, 
newer  versions  of  the  operating  system  are  available.  This 
usually  happens  without  major  disruption  to  the  utilities 
and  applications  utilizing  the  operating  system.  (Of  course 
this  is  not  true  if  an  organization  has  modified  the  oper- 
ating system.)  Hardware  is  also  planned  to  be  upwardly 
compatible.  Prime  Computer,  Inc.'s  50  series  is  an  example 
of  a  compatible  hardware  family.  With  this  marketing  stra- 
tegy, an  organization  can  move  up  to  a  more  powerful 
processcr  without  major  re-writes  or  disruptions.  The 
computer  manufacturers,  in  short,  plan  long-range  migration 
paths  for  their  customers.  Some  examples  are  the  facilities 
in  a  new  operating  system  may  lead  the  way  to  future  hard- 
ware change,  or  a  software  architecture  is  planned  to 
accommodate  future  machines.  Therefore,  the  Coast  Guard 
must    adopt    a   similar    strategy. 

The  initial  environment  the  Coast  Guard  will  be 
dealing  with  is  a  stand-alone,  large  minicomputer  including 
the  operating  system,  utilities  such  as  compilers,  sort 
routines,  etc,  and  OEMS  software.  For  discussion  purposes, 
it  is  assumed  there  is  a  front-end  processor  to  handle  the 
terminal  commun icat icn  protocols.  In  the  District  Offices, 
compatible  machines  will  reside  with  compatible  software. 
This  cannot  be  an  assumption  with  regards  to  the  other 
computer  systems' within  the  Coast  Guard.  For  example,  the 
Operational  Computer  Center  (OCC)  uses  Prime  750s,  while  a 
Headquarter 's   Office      may   be    use      a   7AX-11/780-  There   are 

three  migration  paths  available.  The  first  is  a  migration 
up  to  larger  processors,  the  second  is  creation  of  a  network 
of  minicomputers,  and  the  third  is  use  of  a  smaller  minicom- 
puter   as    a    back-end    database    machine. 
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If  the  pg"ch'  chosen  were  migration  -^c  a  larger,  more 
powerful  processor,  then  a  requirement  fcr  not  having  to 
re-write,  the  application  programs  and  library  rouiines, 
would  most  certainly  te  mandatory.  To  avoid  this  re-writing 
evolution,  one  irust  have  compatibility  of  hardware,  oper- 
ating system,  and  DBMS  software.  Incompa-ibilixy  in  or 
among  any  of  these  features  will  require  some  re-writes. 
Maintaining  the  compatibility  of  hardware  and  operating 
systems  is  a  slier  possibility  in  a  federal  agency  because  of 
the  procurement  restrictions  of  the  Brook's  Act.  Providing 
for  a  competitive  procurement  and  requiring  compatible  hard- 
ware, operating  system,  and  DBMS  software  is  a  zask  with 
little  chance  of  success.  If  this  migration  path  were 
chosen,  the  Coast  Guard  should  be  prepared  to  do  some 
re-writes  of  the  application  programs,  and  in  some  cases 
•major'    re-writes. 

The  second  option  is  to  create  a  network  of  minicom- 
puters, where  the  procurement  of  a  new  minicomputer 
represents  a  new  node  in  a  new  network  structure.  Certainly 
this  will  increase  the  'computing  power'  of  the  system,  but 
new  problems  ar€  introduced  with  this  approach.  If  the 
configuration  is  to  have  both  processors  access  the  same 
data,  then  linking  the  two  processors  together,  and 
providing  for  synchronization  of  reads  and  writes  will  ba 
required.  At  th<=  present  time  this  is  not  a  common  approach 
and  the  experience  base  is  no"c  large.  It  is  the  author's 
understanding  that  Battelle  Labs  of  Columbus,  Ohio,  who  are 
developing  the  Marine  Safety  Information  System  (MSIS) ,  are 
proposing  an  architecture  similar  to  this.  The  experience 
they  are  gaining  in  this  effort  of  linking  several  Prime  750 
computers      together      should      be        very      valuable.  Another 

approach  within  this  option  is  the  creation  of  a  network  of 
minicomputers  by  adding  another  layer  of  software  -  the 
network   operating  system.         This   is      similar   to    IBM's   System 
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Network  structure  (SNA)  which  allows  many  processors  to  be 
hooked  toqether.  The  problem  here  is  that  the  additior.  of 
the  network  operating  system  and  another  processor  may  not 
relieve  the  burden  of  the  DBMS  functions  on  the  first 
machine.  Also  a  number  of  these  networks  like  SNA  support 
only  the  manufacturers  equipment.  Thus  the  Coast  Guard  must 
again   contend   with   the  Brook's   Act   in    the   procurement    arena. 

The  third  option  is  the  use  of  a  back-end  database 
machine.  As  discussed  in  Chapter  IV,  this  is  an  emerging 
technclcgy  where  one  is  truly  working  within  the  state-of- 
the-art.  The  advantages  of  a  back-end  database  machine  is 
its  ability  to  handle  a  heterogeneous  environment  easier 
than  the  ether  two  approaches.  However,  loading  of  the  data 
from  the  host  to  the  back-end  may  be  extremely  difficult  if 
the  hosx  say  supports  a  CODASYL  approach  and  the  database 
machine  supports  a  relational  approach.  This  migration  path 
at  present  is  the  most  expensive  and  difficult  to  achieve  of 
the  three,  and  the  percent  usage  of  the  host  to  DBMS  func- 
tions will  determine  if  this  migration  pa"^h  is  even 
cost-effective. 

In  summary  option  one,  migration  to  a  larger 
processor,  is  easiest  to  implement,  and  there  is  more  know- 
ledge and  experience  about  this  migration  path  than  any 
other.  The  seccnd  solution  is  harder  than  -^he  first,  and 
the  database  machine  is  possibly  the  hardest  because  it  is 
current  state-of-the-art  and  there  does  net  seem  to  be  much 
experience   to   date   with  this  alternative. 

D.       HETEBOGENEOOS   YEESOS    HOMOGENEOOS    SYSTEHS 

Distributed  database  technology  requires  a  hard  look  at 
the  problems  one  encounters  when  examining  heterogeneous 
systems  -  heterogeneous  systems  are  interconneted  proces- 
sors,     software,         and  da-ca    structures    that      are    dissimilar. 
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There  ars  three  (3)  main  problems  when  dealing  with  hetero- 
geneous systems  at  the  database  management  level.  First, 
different  types  cf  database  software  are  incompatible  (even 
without  considering  distributed  databases)  .  Second,  file 
structures  are  expensive  to  convert  to  other  file  structures 
or  database  structures.  Finally,  even  if  all  the  software 
is  compatible,  problems  may  arise  from  incompatible  data 
fields  and  data  structures  due  to  inadeguate  data  adminis- 
tration in  an  organization.  Although  there  is  at  present 
little  need  to  distribute  data  bases  in  the  Coast  Guard, 
later  efforts  to  do  so  will  be  inhibited,  if  there  is  not  an 
early  commitment  to  database  technology  which  requires  the 
data  bases  in  an  organization  to  be  compatible.  Therefore, 
the  emphasis  should  be  on  developing  homogeneous  systems  - 
homogeneous  systems  are  interconnected  processors,  software, 
and    data    structures    that   are    similar. 

One  realizes  that  the  Coast  Guard  survives  in  an  envi- 
ronment of  r.egulations  that  strongly  discourages  the 
development  of  homogeneous  systems.  The  Federal  Procurement 
Regulations  requiring  procurements  to  be  comperitively  bid 
is  one  such  regulation.  There  are  some  exceptions  to  this 
rule,  but  they  are  such  that  the  Coast  Guard  cannot  in 
general  apply  th€se  exceptions.  The  approach  taken  by  the 
District  Minicomputer  Project  is  one  solution  to  providing 
for  a  high  degree  of  compatibity.  A  similar  effort  must  be 
undertaken  at  the  Headquarters  level  if  one  expects  to 
distribute  data  bases  to  meet  higher  goals.  At  the  present 
time,  the  cost  ar.d  degree  of  technological  sophistication  is 
more  than  the  Coast  Guard  can  handle  in  distributing  hetero- 
geneous systems.  Therefore,  emphasis  should  be  placed  on 
developing  hofflog'=neous  systems,  not  on  trying  to  distribute 
present-day   heterogeneous  systems. 
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E.       SDMMAEY 

The  Coast  Gusrd  is  ccrammitted  to  investing  in  the  archi- 
tecture of  the  future  roday,  so  that  the  Coast  Guard  may 
become      an    'information      corporation*    of      -^he    1990 's.  The 

consequence  of  this  is  an  exponential  growth  in  coraput.er 
systems  over  th€  next  few  years.  An  important  aspect  of 
these  computer  systems  will  be  database  management  system 
technology.  A  Coast  Guard  DBMS  has  the  following  require- 
ments -  provide  for  multiple  views  of  data,  provide  for 
acceptabl€  performance,  minimize  cost,  minimize  redundant 
data  items,  support  guery  and  report  generation,  provide  for 
integrity  of  th€  database,  provide  for  both  security  and 
privacy  access  control,  and  support  -he  three-level  hier- 
archy. The  Ccast  Guard  must  protect  its  intellsctual 
development  during  this  period  by  developing  data  bases  by 
subject  area  instead  of  by  application,  requiring  a  data 
dictionary  system,  and  committing  itself  to  provide  quali- 
fied database  administrators.  Orderly  growth  must  be 
determined  by  a  migration  path  now  instead  of  jusz  letting 
happen.  In  most  cases  the  simplest  solution  is  to  use 
he  more  advanced  technology  provided  by  the  original 
vendor;  however,  the  creation  of  a  minicomputer  network  may 
be  feasible  as  t^ie  Coast  Guard  gains  more  experience  in  the 
computer  field.  Finally  the  Coast  Guard  should  strive  now 
to  develop  homoq-^neous  systems  instead  of  trying  to  distri- 
bute   present-day   heterogeneous   systems. 


—   L. 


L 
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VII.     CONCLOSIONS 

The  following  are  the  conclusions  which  zhe  researchers 
have    fcriEUlated    as    a    result    of   their    thesis   research. 

First,  the  Coast  Guard  should  design  its  information 
systems  for  change.  The  rearchers  have  discussed  the  need 
for  system  designers  to  be  conscious  of  the  effect  which 
technological  change  has  had,  and  will  continue  to  have  in 
the  computer  industry.  The  Coast  Guard  does  not  want  to 
lock  itself  out  of  any  promising  technological  advances 
which  will  occur,  and  it  must  also  recognize  the  need  for 
growth  and  change  in  user  requirements.  Therefore  the  Coast 
Guard  should  develop  flexible  systems  which  are  amendable  to 
future   change. 

Second,  the  researchers  have  pointed  out  that  since  the 
Coast  Guard  is  relatively  new  at  procuring  information 
systems,  the  need  to  have  sophisticated  computer  networks, 
such  as  IBM's  SNA,  is  net  warranted  at  this  time.  This 
policy  is  in  accordance  with  prudent  evolution,  and  leads  to 
the  conclusion  that  there  will  nor  be  a  great  deal  of  data 
sharing  required  among  various  Coast  Guard  organizational 
elements  initially,  although  it  must  be  recognized  that  in 
the  future  -^he  Ccast  Guard  may  need  to  create  these  sophist- 
icated computer  networks  (or  distribu-^-ed  systems).  In  order 
to  support  future  networking  possibilities,  it  is  recom- 
mended that  the  Coast  Guard  strive  for  homogeneous  systems 
as  much  as  possible  so  that  this  interconnection  is  much 
easier  -^c  accomplish.  The  Coast  Guard's  scarce  resources 
dictate  that  connecting  heterogeneous  systems  be  postponed 
at  this  time,  ar.d  its  efforts  directed  toward  the  develop- 
ment   of    homogenous   systems. 
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Third,  the  authors  have  concluded  that  -^.he  Coast  Guard 
should  require  good  documentation  of  all  of  the  systems 
which  are  developed  and  installed.  Being  a  military  organi- 
zation implies  e  great  deal  of  personnel  rotation,  and 
therefore  in  order  that  new  personnel  coming  aboard  under- 
stand, operate,  and  maintain  the  system,  good  documentation 
is  essential  becuase  there  probably  won't  be  anyone  around 
who    was    present    at    installation    after    a    few    years. 

Fourth,  the  researchers  have  concluded  that  the  Coasx 
Guard  should  stress  the  importance  of  human  needs  in  the 
systems      which      it      develops   and      acquires.  By      this      the 

researchers  are  pointing  to  the  need  for  systems  to  be  easy 
to  learn  as  well  as  easy  to  use  in  order  that  personnel  be 
more  compelled  to  use  the  systems  to  assist  in  their  job 
activities,  and  thereby  the  system  be  more  responsive  to 
user  requirements.  Other  human  factors  which  should  be 
considered  by  th<=  Coast  Guard  include  training  and  education 
and  involving  erd  users  in  the  design  and  development  of 
systems . 

Fif-^h,  the  authors  have  concluded  and  recommend  that  rhe 
Coast  Guard  should  establish  database  administrator  posi- 
tions throughout  the  organization,  and  it  should  seek  to 
fill      those      positions   with      talented      professionals.  The 

duties  of  -^he  database  administrator  and  staff  have  been 
discussed  in  previous  chapters,  and  the  researchers  consider 
that  this  position  is  vital  to  the  success  of  the  proper 
management    cf  any  organization's   data    base  (s)  . 

Sixth,  a  key  tool  which  the  database  administrator 
should  have  is  a  data  dictionary.  The  data  dictionary  is 
essential  to  assist  ^n  implementing  subject  area  databases, 
to  maintain  consistency  throughout  the  organization,  xo 
identify  sources  and  uses  of  the  data  resources,  and  to 
construct  standards  and  procedures  for  those  data  resources. 
The  data  dictiorary  must  be  a  requirement  for  the  Coast 
Guard   to    be   successful  in   implementing    database   technology. 


Sev<rn-^.h  and  finally,  a  Coast  Guard  DBMS  should  include 
the  fcllowing  requiremen-cs  :  provide  for  multiple  views  of 
data,  provide  for  acceptable  performance,  minimize  cost, 
minifflizfe  redundant  data  items,  support  query  and  report 
generation,  provide  for  integrity  of  the  database,  provide 
for  both  security  and  privacy  access  control,  and  support 
the   three-level    hierarchy. 
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APPENDIX    A 
RE  SOURCES 

I.  Personnel  Resources.     These  are  approximate  figures,  subject  to  change. 
a.  Headquarters  (does  not  reflect  interim  reassignments ) : 
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G-TFP 

6 

0 

6 

1 

13 

G-TNR 

6 

0 

8 

0 

14 

TOTAL 


71       17       50      86 


224 


b.  District  Offices: 

Dist  otm  eee  fds  inn  TOTAL 

CO  WD  EN  CV  TOT     CO  WD  EN  CV  TOT     CO  WD  EN  CV  TOT     CO  WD  EN  CV     TOT 


1  :  2 

3  16 

0 

21  :  3 

3 

10 

5 

21  :  0 

0 

0 

7 

7  :  2 

0 

0 

3 

:  52 

2  :  1 

1  10 

0 

12  :  2 

1 

0 

0 

3  :  0 

0 

0 

5 

5  :  2 

0 

0 

3 

:  23 

3  :  2 

3  24 

0 

29  :  3 

3 

5 

5 

16  :  0 

0 

1 

10 

11  :  2 

0 

0 

3 

:  59 

5  :  2 

2  15 

2 

21  :  2 

3 

1 

4 

10  :  0 

0 

0 

8 

8  :  2 

0 

0 

3 

:  42 

7  :  2 

2  17 

0 

21  :  3 

3 

3 

3 

12  :  0 

0 

0 

5 

5  :  2 

0 

0 

3 

•  41 

8  :  2 

3  14 

1 

20  :  2 

4 

2 

1 

9  :  0 

0 

0 

5 

5  :  2 

0 

0 

3 

•  37 

9  :  2 

2  13 

0 

17  :  2 

2 

2 

5 

11  :  0 

0 

0 

6 

6  :  2 

0 

0 

3  . 

37 

n  :  1 

2  10 

0 

13  :  2 

2 

1 

3 

8  :  0 

0 

0 

5 

5  :  4 

0 

0 

5 

.  31 

12  :  2 

2  17 

1 

22  :  2 

3 

1 

2 

8  :  0 

0 

0 

6 

6  :  2 

0 

0 

3  • 

•  39 

13  :  2 

2  12 

1 

17  :  3 

3 

3 

3 

12  :  0 

0 

0 

6 

6  :  2 

0 

0 

3  : 

38 

14  :  2 

3  14 

1 

20  :  3 

2 

4 

3 

12  :  0 

0 

0 

6 

6  :  2 

0 

0 

3  : 

41 

17  :  2 

3  21 

1 

27  :  5 

4 

4 

1 

14  :  0 

0 

0 

5 

5  :  2 

0 

0 

3  : 

49 

TOT  22  28  183  7  240     32  33  36  35  136       0     0     1  74     75     26  12     0     0     38     489 


DISTRICT  TOTALS 


00      WD     ENL     dV        TOTAL 
80      73    220     116  489 


106 


c.  Area  Offices: 

00  WD  ENL  CIV  TOTAL 

Atlantic       7  3  3  0  13 

Pacific       6  3  U  0  13 


13   6   7   0     26 

d.  CoBamunicationa  Stations  and  Radio  Stations 


Boston 

1 

3 

64 

0 

68 

Portsmouth 

2 

2 

82 

3 

89 
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1 

1 

30 

1 

33 

San  Juan 

0 

1 

18 

0 

19 

New  Orleans 

0 

2 

43 
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.45 
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2 

3 

87 

1 

93 
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0 

1 

27 

0 

28 

Honolulu 

1 

1 

49 

0 

51 

Kodiak 

2' 

2 

81 

0 

85 

TOTAL         9   16  481    5    511 


e.  Laboratories 

EECEN         17    6   87   25    135 
Sta  Alexandria   8   5   54   22     89 


25   11  141   47    224 

f.  Electronic  Shops  (ES,  E34,  EST,  ESMT,  Yard) 

1   18  414  112    545 

g.  Other  (Vessels,  LORAN  Stations,  etc.) 

91  110  1475   0    1676 


GRAND  TOTAL       290  251  2788  366    3695 
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APPENDIX    B 
SDD-1 

INTRODUCTION 

SDD-1  [Ref.  26],  was  developed  by  Computer  Corporation 
of  America  and  supported  by  the  Defense  Advanced  Research 
Proiect  Agency  of  the  U.S.  Department  of  Defense.  It  is  a 
system   fcr    iranaging    data   bases      whose    storage   is   distributed 


Figure    B.I         SDD-1    Architecture. 

ever    a   network    of  computers.  The   general   configuration    of 

SDD-1    is    given       in    Figure   B.I   and   consists      of  three    virtual 
machines;      Transaction   Module    (TM)  ,    Data    Module    (DM),       and   a 


108 


Reliatle  Networl<"  (RELNET)  .  ?1ore  about  these  'vir-^.ual* 
machines  later.  SDD-1  is  based  upon  relational  da*a  struc- 
tures because  complex  data  operations  can  be  sinipler  and 
mere  precise  than  when  data  structures  are  used  which  are 
not    two-dimensional.  It    is      believed    by      the   creators      of 

SDD-1  that  this  type  of  architecture  is  appropriate  for 
activities  requiring  access  to  a  single  pool  of  information 
distributed  over  a  wide  geographical  area.  It  permits 
decentralized  processing  for  performance,  reliability  and 
flexibility   of    function   reasons. 

Users  interact  with  S ED-1  in  a  high  level  language 
called  Eatalanguage  which  is  in  fact  a  general  purpose 
programming  language.  The  data  stored  at  "^he  nodes  of  SDD-1 
are  portions  of  a  relation  which  may  be  either  a  vertical 
subset  composed  of  specified  fields  of  the  relation  or  a 
horizontal  subset  defined  ty  one  or  more  expressions  e.g. 
Value  of  Field  Id  #  =  WAGE.  Figur^'  B.  2  represents  a  'hori- 
zcntal»      fragment  and     Figure      B.3      represents   a      'vertical' 
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Figure    B. 2        Horizontal   Fragment    of   a   Relation- 
fragment.  A      fragment      is  either      completely      present      or 
completely   absent   at    any   node    (DM)         and   any    fragment    may   be 
stored   redundantly   at    more    than   one   Data    Module    (DM). 


109 


SHIP 

INAME 

ID               HOMEPORT 

STATUS               1 

ICE_1A 

|ICE_  1A.  1 

1     ICE. 

.1A. 

2 

1       ICE_1A.3               1 

ICI_1E 

|ICE_1B,  1 

1       ICE_1B.2               1 

ICE_1C 

|ICE_  1C.  1 

1    ICE_1C.2 

1       ICE_1C.3               1 

ICE_2A 

|ICE_2A.  1 

1    ICE_2A.2 

ICI    2E 

IICE-2B.  1 

!       ICE    2B.2               1 

ICE_1A.1    =    (Nam€    =    GLACISR;Id    =    WAGB-U) 
ICE     1A. 2    =    (Homeport    =   San    Francisco) 
ICEI1A.3    =    (Status   =    Ops) 

etc  . 


Figure  B.3        Vertical   Fragment    of   a    Relation- 

The  iraplems  r.tat  icn  of  a  distributed  database  system 
presents  three  fundamental  problems;  concurrency  control, 
distributed  query  processing,  and  reliable  posting  of 
updates.  Each  cne  of  these  problems  can  be  associated  with 
one  of  three  functions  for  distributed  database  technology. 
For  example,  concurrency  control  can  be  associated  with  the 
functions  of  database  management,  likewise  distributed  query 
processing  with  management  of  distributed  transactions,  and 
reliable  posting  of  updates  with  distributed  data  base 
management  system  reliability.  The  authors  of  SDD-1  have 
placed  each  one  of  these  problems  in  a  distinct  processing 
phase  -  Read,  Execute,  and  Write.  Furthermore,  each 
processina  phas€  is  contained  in  one  of  the  *  virtual' 
machines  mentioned  earlier,  i.e.  Data  Module  (DM), 
Transaction  Module  (TM)  ,  and  Reliable  Network  (RelNET)  .  The 
functions    of    the   Data   Module   are   to   respond    to: 
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1.  EEAC  part  of  the  Data  Module's  data  base  into  a  local 
workspace   at   that   Data    Module, 

2.  MOVE  part  of  a  local  workspace  from  this  Data  Module 
to   another    Eata    Module. 

3-  HANIFULATE  data  in  a  local  workspace  at  the  Data 
Module . 

4.  WRITE  Dart  cf  the  local  workspace  in*c  the  permanent 
data    base   stored   at   the    Data   Module.      [Ref.    26:    p-    5] 

The    functions   of  the    Transaction    Module    plan   and   control   th=» 

distributed      execution  of      transactions.  It   performs      the 

following    tasks. 

1.  FRAGMENTATICN:  The  Transaction  Module  translates 
queries  on  relations  into  queries  on  logical  frag- 
ments and  decides  which  instance  of  stored  fragments 
to    access. 

2.  CONCURRENCY  CONTROL:  The  Transaction  Module 
synchronizes  the  transaction  with  all  other  active 
transactions    in    the   system. 

3.  ACCESS  PLANNING:  The  Transaction  Module  compiles  the 
transaction  into  a  oarallel  program  which  can  be 
executed  cooperatively    by    several    Data    Modules. 

a.  DISTRIEaTED  QUERY  EXECUTION:  The  Transaction  Module 
coordinates  execution  of  the  compiled  access  plan, 
exploiting  parallelism  whenever  possible.  [Ref-  26: 
p.    51 

Lastly,      the    Reliable   Network   interconnects   the    Data    Modules 

and    Transaction     Kodules    -o    provide   for: 

1.  GUARANTEED  EELIVERY;  allowing  messaaes  to  be  deliv- 
ered even  if  the  recipient  is  down  at  the  time  the 
message  is  sent,  and  even  if  the  sender  and  receiver 
are   never   up  simultaneously. 

2.  TRANSACTION  CONTROL:  a  mechanism  for  pcsring  updates 
at  multiple  Data  Modules  guaranteeing  that  either  all 
Da-^a    Modules   pest   the    update   or    none    do. 

3.  SITE  MCNITOFING;  to  keep  track  of  which  sites  have 
failed,    and   to    inform    sixes   impacted    by   failures. 

4.  NETWORK  CLOCK;  a  virtual  clock  kept  approximately 
synchronized  at    all    sites.      [Ref.    26:    p.    5*] 

The  rest  of  this  appendix  will  be  concerned  with  a  descrip- 
tion of  how  3CD-1  solves  the  three  problems  mentioned 
earlier. 
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CONCUERENCY    CCNTFOL: 

In  a  centralized  database  management  system  concurrency 
problems  are  hardled  by  simply  locking  the  database  until 
the  write  operation  has  been  completed.  This  has  been  the 
approach  taken  by  mcst  implementors  of  a  distributed  data- 
base technology;  however,  locking  in  a  distributed  database 
system  with  a  high  level  cf  updates  can  cause  substantial 
performance  degradation  because  there  is  no  activity  allowed 
on  the  data  until  the  update  is  complete.  On  a  distributed 
system  where  the  data  has  many  copies  the  performance 
problem   becomes    even    mere  severe. 

A  system  will  provide  for  concurrency  control  if  the 
system  can  provide  for  se rializabili ty.  The  property  of 
ser ializability  is  that  the  interleaved  operation  of  the 
sysrem  is  eguivalent  to  one  in  which  the  transactions  are 
run  to  completion,  one  at  a  time,  serially.  Hence  serializ- 
ability  requires  tha*  whenever  transactions  execute 
concurrently,  their  effect  mnsz  be  identical  to  some  serial 
(i.e.  non-inter  1  €aved)  execution  cf  -hose  same  transactions. 
Two  major  types  of  conflicts  occur  to  prevent  serializ- 
ability;         update        conflicts      and        read      conflicts.  If 

transactions  are  grouped  into  classes  based  on  which  Data 
Module  executes  the  transaction  and  what  data  the 
Transaction  Module  uses  then  potential  conflicts  between 
classes  can  be  analyzed.  This  is  exactly  what  is  done  by 
the  data  base  administrator  at  design  time,  and  is  known  as 
conflict    analysis. 

With  conflict  graph  analysis  the  Data  Base  Administrator 
(DBA)  defines  transaction  classes  which  are  named  groups  of 
commonly  executed  transactions.  These  transactions  are 
defined  by  its  rame,  read-set,  write-se-'-  and  Transaction 
Module  at  which  it  runs.  Figure  B.U  is  an  example  of  an 
update      conflict.  Through    conflict      graph      analysis      four 
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Figure   B.4         Conflict    Graph. 

different  situa'rions  may  arise  each  requiring  different 
synchronization  protocols.  They  are;  no  conflict,  updat.e 
conflic-^.,  read  conflicx  with  one  Data  Module,  and  read 
conflict    wi-*-h   more    than   one    Data    Module. 

To  solve  the  update  conflict  the  two  transactions  must 
be  synchronized,  i.e.  one  musr  be  run  first  and  the  other 
delayed      un-^il   the      first   transaction      is   completed.  This 

order  of  processing  transactions  is  de-ermined  by  the  total 
ordering   of      trarsactions  induced      by   timestaraps.  This   is 

accomplished  by  piping  which  requires  each  Transaction 
Module  to  send  its  Write  commands  in  timestamp  order.  One 
should  note  that  the  'virtual'  clock  does  not  have  to  be 
absolutely  synchronized  at  each  site  as  the  Transaction 
Module  identifier  is  attached  to  each  timestamp,  thus 
ordering   the   tim€staiDps   globally. 

Thus  through  conflict  graph  analysis  a  DBA  can  loosen 
the  restrictions  on  the  synchronization  protocols  for  those 
transactions    that   may  noi:   conflict.         This    in  turn    increases 
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system      performance.  The      technique      of      piping      achieves 

consister.cy  and    ser  ializabi  lity    throughout    the  syst'=m. 

DISTEIEDTEC    QDEEl!   PRCCESSING 

In  processing  a  query  in  a  distributed  mode  one  can  take 
the  straight  forward  approach  and  move  all  the  transactions' 
read-sets  to  a  single  Data  Module  and  then  execute  the  ■tran- 
saction. This  however,  is  quite  prohibitive  in  terms  of 
communication  costs  for  vary  large  read-sets  and  no  use  is 
made  cf  parallel  processing.  SDD-1  attempts  to  solve  this 
problem  by  splitting  query  processing  into  two  distinct 
phases.  The  first  phase  reduces  the  read-set  as  much  as 
possible  without  changing  the  transaction's  answer.  This 
reduces  the  amount  of  data  to  be  transmitted  between  sites 
and  makes  efficient  use  of  parallel  processing  as  a  transac- 
tion may  fce  worked  on  concurrently  at  more  than  one 
Transaction  Module  at  once.  The  final  phase  transmitts  the 
reduced  rea3-set  to  the  final  Data  Module  where  the  Transac- 
tion is  executed.  A  temporary  file  (buffer)  is  created  at 
the  final  Data  Module  so  that  the  answer  to  the  transaction 
can  be  written  "^o  the  database  or  displayed  whichever  was 
requested. 

RELIABLE    WRITING 

There  are  three  potential  problems  that  must  be  solved 
to  insure  that  updates  are  reliable.  The  first  is  to  guard 
against  a  failure  of  a  receiving  Data  Module,  i.e.  must  have 
reliable      delivery.  The      second   is      to      take      appropriate 

measures  when  a  failure  occurs  at  the  point  of  origin,  i.e. 
transaction  contrO"l.  Finally  the  system  must  insure  updates 
to  different  transactions  are  installed  in  the  same  'effec- 
tive'   order   at    all    Data    Modules. 


iia 


The  first  prcblem  is  handled  by  a  mechanism  the  creators 
called   spooler.  It    is   a      function/process    with      access    to 

secondary  3torag€  devices  that  serve  as  first-in,  first  out 
(FIFO)  message  queues  for  a  failed  site.  Thus  any  message 
sent  to  a  site  ^ihich  has  failed  will  be  re-routed  to  the 
spooler  instead.  Once  the  failed  site  comes  back  on-line 
updates  from  ths  spooler  are  processed  by  the  failed  Data 
Module. 

The  second  problem  -  transaction  control  -  is  handled  in 
a  more  subtle  way  with  a  technique  that  employes  a  variant 
of  the  two-phase  commit.  During  phase  1  the  file  'F'  is 
segregated  into  'n'  number  of  files  corresponding  to  the 
receiving  Data  Modules.  For  example  file  'F'  will  be  split 
into      files      F  ( 1 ) ,.  .  .  ,F  (n)  to      be      sent      to      Data      Modules 

DM(1)  r...,DM(n)  .  The  receiving  Data  Modules  do  not  install 
these  files  yet.  This  completes  phase  1.  During  phase  2 
the  Data  Module  that  originated  the  transaction  sends  a 
commit  message  tc  each  DM  (1  )  , . .  .  ,DM  (n)  where  upon  each  DM  (i) 
installs  F(i).  If  seme  DM  (k)  has  received  F  (k)  ,  but  not  a 
commit,  and  the  Data  Module  that  originated  the  transaction 
has  failed,  then  the  DM  (k)  consults  other  DM's  affected  by 
the  transaction.  If  any  of  the  affected  DM*s  have  received 
a  commit  then  DM  (k)  proceeds  to  install  F  (k)  .  If  no  ether 
affected  DM  has  received  a  commit  th*  transaction  is 
aborted. 

Problem  three,  insuring  updates  to  different  transac- 
tions are  installed  in  the  same  'effective'  order  at  all 
Data  Modules,  is  handled  quite  easily.  Since  every  physical 
data  item  in  the  data  base  is  timest'amped  with  the  most 
recent  updated  transaction,  and  each  update  (Write  command) 
carries  the  timestamp  of  the  Transaction  Module  that  gener- 
ated it;  the  following  write  rule  is  applied:  For  each  data 
item,  'x'  in  the  update,  the  value  of  'x'  is  modified  at  the 
Data    Module   if    a  r.d   only    if    x's  stored    timestamp   is    less    than 
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the  timestamp  of  the  write  command.  The  overhead  of  time- 
stamps  on  each  data  item  is  reduced  to  acceptable  levels  by 
caching  the  timestamps  according  to  the  authors  of  SDD-1. 

SDMMAEY 

SDD-1  relies  heavily  on  the  use  of  directories  to  main- 
tain the  location  of  data  throughout  the  system.  For  SDD-1 
to  be  effective,  the  management  of  these  directories  must  be 
efficient  and  flexible.  The  approach  taken  by  the  authors 
is  to  treat  the  directories  just  like  data,  hence  directory 
management  is  a  design  issue.  Therefore,  the  directories 
can  be  fragmented,  distributed  with  arbitrary  redundancy  and 
updated    from   arbitrary  Transaction   Modules. 

The  develop  iient  of  SDD-1  uses  a  relational  database 
management  system  called  Datacomputer  and  runs  on  PDP-10 
equipment  using  the  ARPANBT  and  the  communication  network. 
The  different  modules  require  a  fair  amount  of  main  memory 
for  the  object  cede,  but  not  an  unreasonable  amount.  There 
does  however,  exist  two  fundamental  problems  with  SDD-1  for 
the  Coast  Guard.  The  first,  the  equipment  is  all  homoge- 
neous, hence  coaplexities  are  reduced  somewhat.  Here  the 
Coast  Guard  can  rot  expect  to  ever  be  in  the  position  of 
having  homogeneous  systems  in  the  near  future.  Secondly, 
the  Data  Base  Ad  linistrator  (DBA)  has  a  difficult  job  just. 
to  create  a  logical  database  design.  In  fact  there  are  few 
examples  of  corporations  that  have  had  great  success  with 
this  fundamental  approach  to  the  use  of  database  technology. 
The  Data  Base  Administrator's  job  becomes  ever  more  complex 
by  having  tc  perform  the  conflict  graph  analysis  and  split- 
ting transactions  into  different  classes.  Although  the 
Coast  Guard  has  mny  talented  people,  to  find  this  required 
talent   would   be    a  herculean    task. 
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